* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit intends to fix two strange bugs encountered while trying to
push a new component into the systray menu:
- MessagingMenuWidget and RtcActivityNoticeWidget were removing their
parent node via DOM manipulations when attached in the DOM. This caused
a crash when adding other items to the systray menu since the deleted
nodes were actually managed by OWL.
- The t-foreach directive in the navbar used indexes as the t-key, which
led mapping items subsequently added to wrong templates.
closesodoo/odoo#78784
X-original-commit: 5f0f80da4fc951954d253c9e45defd591605f556
Related: odoo/enterprise#21829
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Ooming <oomsveta@users.noreply.github.com>
Before this commit: when creating scheduled activity from activity cell
activity type was not passed in context due to which default activity type not
set, to produce: CRM -> Activity View -> Click on existing record of activity
view which will open popover -> click on Scehdule Activity button, this will
open scheduled activity form but it will not have default activity type.
After this commit: when clicking on Scehdule Activity button from activity
popover, default activity type will be passed in context.
task-2568793
closesodoo/odoo#78330
X-original-commit: 17cbafdd1ce4f5f095512677d5b3750e3a8dc889
Signed-off-by: Simon Genin (ges@odoo) <ges@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>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
We move /commands to /core because DebugMenu depends
on /command/command_hook. All the files in /commands depend only
on /core or /commands except for menu_providers which we will move to /menus
X-original-commit: eca8cd478b72d81b2293c22d2c9c41d1f94be16a
Part-of: odoo/odoo#76777
This reverts commit 2623b4591d.
The command+m shortcut on safari is not listenable. Safari prevents to
catch events of some shortcut reserved for OS actions. Command+m is
used to minimize the app. This makes it impossible to open the command
palette on safari. So we decided to use again the command+k (ctrl+k)
to open the command palette.
X-original-commit: ca0e37cc20da907d74245e935416d66a52976c5e
Part-of: odoo/odoo#76614
Current implementation switch display between file attachment and image
attachment. This commit split those behavior in 2 components.
Part of task-2365881
closesodoo/odoo#76541
X-original-commit: 0a0f37f6645f1196e3a6d104e8592a1a362058db
Related: odoo/enterprise#20880
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Change the command palette shrotcut from CTRL+K to CTRL+M,
in order to avoid conflict with link creation shortcut in editor.
task-2635043
closesodoo/odoo#75828
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds the smarts actions:
- Assign to... (many2one_avatar and many2many_avatar)
- Assign/unassign to me (many2one_avatar and many2many_avatar)
- Set priority... (priority)
- Set kanban state... (state_selection)
These smarts actions are commands with hotkeys accessible from
the form views containing the widget to which they are linked.
closesodoo/odoo#75312
Task-id: 2588238
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Channels
* "hash tag" avatar with different backgroud colors
* only private channels have lock thread icon
- DM groups
* "users" avatar with different background colors
* no thread icon
task-2584994
closesodoo/odoo#75653
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose:
=======
This commit adds the project sharing feature. This feature consists to
share the backend views about project.task to portal users.
About the access rights:
- The project manager can share a project with project sharing feature.
To do this, he need to give access to portal users that we want their access in project sharing views.
He can choose between 2 differents accesses:
1. **Readonly**: The use has access to the classic portal views (on which he can post messages, and have a readonly access rights to the related fields)
2. **Edit**: the portal with this access right will can edit some fields of `project.task` model.
The difference between the classic backend views and the project sharing
views is in the project sharing views, we list the fields that the user
can read/write, so the portal users can see only the fields in
our list.
Moreover, the actions and the contextual menu (actions dropdown) are not
available in the project sharing views and the stat buttons are visible
but the click on these buttons are disabled.
Implementation details:
======================
- add `allow_project_sharing` option in project form view.
- create the webclient and routes.
- create own qweb bundle.
- add project sharing views.
- use the session to define the action and active_id
- create public fields for project sharing: in this step, we lists all field
names of the `project.task` model that we want to display for the
portal user. Two lists are created, one for only readable field names
and the other one for the writable field names.
Moreover, two properties are defined in the `project.task` model to use the
both lists.
- use `access_token` and check model in project sharing route: in this
step we check if the model is `project.project` and the `access_token`
is the one set in the project since we have the id of the project in the
params url.
- protect ORM methods: to avoid the portal user has accessed to too much
fields that he can, we have to check if all asked fields are in
the readable fields, if all fields are available for these users than we do the
method, otherwise we raise an `AccessError` exception.
- allow only `GET` method to enter project_sharing routes: the
`/my/project/<int:project_id>/project_sharing` route must only be
called with a `GET` method because this route is only used to have the template
to render the project sharing webclient.
- redirect the link in one of the sharing wizards to project sharing views if the portal user has an access
to the shared project and if the shared project has the Project Sharing feature enabled.
- only load `project.task` views for project sharing.
- remove longpolling in the project sharing.
- disable click on avatar to open the chat with the user or open the hr.employee form because these features are not authorize in the project sharing.
- remove the contextual action menu in the project sharing views
- add the chatter in the `project.task` form for the portal user with at least 'comment' access.
This user could send message and see the public message like portal chatter.
- replace the basic portal views when the portal user selects project in `/my/projects` by the project sharing views if the `allow_project_sharing` is enabled for this project and if the portal user can access to the project sharing views of this project.
Why did we implement this feature in this way ?
====================================
We thought to create a `project.task.portal` model. This model had contained all fields that the portal user can read and edit (`readonly=True` if the portal user can just read the field).
We had 2 possibilities for this solution:
1. link this model with `project.task` either with inherits attribute in `project.task` or by creating a many2one field in the project.task.
The problem with this solution is with `inherits`, we just copy all fields in `project.task` and not method, so we need to duplicate methods used in both models. Moreover, with `inherits` possbility, we have to create all records even if the Project Sharing feature is not used. If we took the other possibility (that is, create the Many2one field in `project.task` model) asks to create records when the `allow_project_sharing=True` in a project and also unlink/archive records when the Project Sharing feature is disabled in a project. The process is harder each time, the user enables/disables the feature. That's why we didn't do this solution.
2. the new model contains a sql view and we use the related field to create/edit tasks in project sharing views.
We don't do this solution because it was a big change and increase the complexity. Moreover, if the sql view gives all tasks of shared projects, we could have a security issue because the portal user could have access to the tasks of shared project in which he didn't have any access.
Another solution that we thought before doing this feature was to create the kanban view in portal. We didn't do that because:
1. the render of this view will not be the same than the one in `/web`,
2. we didn't want to duplicate the kanban view,
3. we need to allow the portal to create/edit task.
task-2379518
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#73341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, there is no options to disable the click on the
avatar to open the chat in `Many2OneAvatarUser` widget.
This commit adds an option called `no_open_chat` set by default to false
and this option allow to disable the click when it is true. This option
is useful for the project sharing views.
task-2379518
closes#73341
The commit is to refactor the discuss sidebar
- threads are now organized in categories based on the thread type e.g. chat, channel
- categories can be folded or unfolded by clicking the category title
- for active thread, even if the category is folded, it remains under the category title
- for channel category, a new cog button is added to view all channels
- the active indicator bar is removed. The active item now is highlighted with a different background color
- thread avatar is used for livechat, chat and channel
- for livechat and chat, threads are now sorted by last activity time (pin or message exchange)
closesodoo/odoo#70986
Task-id: 2440073
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = test_discuss_full
Overall less queries.
Changes:
- Batch `mail_partner_format`.
- Batch `user.employee_id` compute.
- Remove query for current leave state, use fields (and prefetch) instead.
- Move current leave state in partner format instead of channel info.
Part of task-2622462
closesodoo/odoo#73174
Related: odoo/enterprise#20186
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = im_livechat, test_mail
The goal of moving it in models and making it independent of current user is to
be able to test it easily in future commits.
Part of task-2622462
* = crm_livechat, im_livechat, mail_bot, test_mail_full
Those are hard-coded methods just like any other, remove the magic call and the
need to forward them to the client at init.
Part of task-2622462
From this commit, it will be possible to access the chat window
of a partner/thread from the command palette.
In the palette command, if you type :
- @ then it will display partners
- # then it will display threads
TaskID-2593197
closesodoo/odoo#74436
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
The aim of the current task is to adapt the design of this new widget to the
list and kanban views.
SPECIFICATION
Kanban
when there is only one record set in the m2m field, display it like a
many2one_avatar widget when there are two or three records set in the m2m
field, display the avatars next to each other when there are more than three
records set in the m2m field, display the first two avatars, then a grey circle
with +X in it (where X is the number of records beyond the first two), when
hovering the +X avatar, open a tooltip with the list of the remaining records
the display order of the records is the same as the order in the m2m field
the avatars behave like in the other avatar widgets (i.e. darkens on hover and
clicking on it opens the chat) except the +X avatar that does not darken or has
a cursor:pointer; on hover and is not clickable
List
same specs as for the kanban view, with the difference that the widget displays
up to five records instead of three when the widget is editable display it like
the current formview version of the many2many_avatar_user widget (i.e. tags
with avatars)
task-2563591
closesodoo/odoo#72166
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit: When applying active filter using progressbar in activity
view, records are not displayed based on active filter, row was not getting
highlighted based on active filter also other records not getting hidden.
After this commit: When applying active filter in activity view using
progressbar, row will be highlighted and records will be sorted based on active
filter value, like if 'green' color is clicked in progressbar then records with
green color will be displayed on top also other color records will get hidden.
task-2550959
closesodoo/odoo#74405
X-original-commit: 0fbed7291d4d242d663f3b816904525dd5b65c0c
Signed-off-by: Simon Genin (ges@odoo) <ges@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>
This makes the debug menu more natural to use, and makes the difference
between the "in-dialog" and "out-of-dialog" debug contexts explicit.
closesodoo/odoo#74346
Related: odoo/enterprise#19967
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, click on "Schedule activity" in the activity view
would open a dialog in which the search view is the default one on the
current activity view model.
With this commit, we make the dialog use the same search view as the
activity view.
Done to help with the task 2502339
closesodoo/odoo#73697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Returning all the users at init does not scale. Mention suggestion code is good
enough now that this is no longer necessary.
closesodoo/odoo#73689
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
Rationale
=========
Currently, mail channels have 2 modes
- They can be used like Discuss channel (chat, livechat, group)
- They can be used like a Mailing List (with the "email_send" field)
The mix of both feature in the same model causes some code complexity.
Several fields are not used in both cases (moderation related field)
and the future "Discord like" Discuss will even push the mail channel
further than the usage of the mailing list.
Because of all those reasons, we want to split the 2 mains features of
the mail channels into 2 different modules and models.
Purpose
=======
This commit remove the moderation feature of the mail channel
(email_send=True). This will be re-implemented in a separate module
in the next commit.
Do not be able to check messages in Discuss anymore because this
feature is only used to moderate the message and this feature will be
spitted in a new module "mail_group".
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
* google_recaptcha, mail, partner_autocomplete, point_of_sale, website
Now, to read session information, the module "@web/session" must be
imported. Not that, there is also the user service with all the user
information.
closesodoo/odoo#73201
Related: odoo/enterprise#19434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
add resetLocalState method to rendererWrapper and test activity view is not
crashed on on_destroy_callback
task-2466057
closesodoo/odoo#73022
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Currently, activity view does not support many2one_avatar_user widget due to
which clicking on image do not open chat window, with this commit, we add
support of many2one_avatar_user widget in activity_view so that user can click
on avatar image and open chat window.
task-2554466
closesodoo/odoo#71804
Related: odoo/enterprise#18803
Signed-off-by: Simon Genin (ges@odoo) <ges@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>
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
We should not assume that the default date of the message is "now". A message
should only have a date when it's coming from the database that supply it.
closesodoo/odoo#70069
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
with this commit, we adds many2many_avatar_user widget to have same behaviour
as many2one_avatar_user where clicking on avatar image opens chat box, so to
have same feature on many2many_tags which is related to res.users we adds
many2many_avatar_user widget.
task-2451204
with this commit: we improve many2one_avatar widget for editable form view,
previously many2one avatar in edit mode was not displaying image, it was
displaying only many2one selection input, this commit adds image before
many2one input to have unify design with readonly form view.
This is especially motivated by the fact that we plan on getting rid of the
readonly formview to always be in edit mode.
task-2451340
closesodoo/odoo#67366
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Didier (did)