*: base_automation, hr, mail, web, web_tour, website_payment
Previously, some modules were imported twice, this increases duplication
and can make refactoring more difficult. This commit enables the
no-duplicate-imports eslint rule and fixes offending modules to remove
duplicates.
closesodoo/odoo#84530
Related: odoo/enterprise#24319
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This reverts commit 0e1961b1dd because the
`no_open_chat` option is removed, this commit becomes useless, that's
why the commit is revert.
task-2633229
Closes#82379
- Open any record with a chatter (i.e. a SO)
- Log a note with a mention to any res.partner
- Edit note and save
The mention is not a link anymore, but just plain text.
During edition the list of mentioned partners is not retrieved correctly,
preventing function that generates links from mentions to work properly.
On client-side, a variable named MentionedPartners is used to generate
mention links when posting a message.
It should contain the id and name (to match the mention text) of each
mentioned partners.
During edition, MentionedPartners is empty, leading to this issue.
As the list of mentioned partners is stored in message model in partner_ids
field, "id" and "name" of partner_ids will be retrieved and added to messages
data when requested by client side.
This will allowed to populate MentionedPartners with all required data.
Note that retrieving "name" from partner_ids will add an extra query,
as seen in the modified test.
opw-2739665
closesodoo/odoo#84152
X-original-commit: 510764730057b20a1706ae20d50549e280f7f9a7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some recent changes have evidenced that the modification of the activity
type of an 'upload_file' activity was not properly covered by the tests.
This commit adds a new test for this specific case.
Part of task-2730667
closesodoo/odoo#82498
Signed-off-by: Sébastien Theys (seb) <seb@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>
Before this PR the only purpose of the file_uploader component was to inject a
`<input type="file">` inside the DOM.
We can now create this input directly inside the FileUploader model without
register a component.
task-2727815
closesodoo/odoo#82213
Related: odoo/enterprise#23261
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Invalid data provided at record creation were silently skipped by the
framework without triggering an error. This commit ensures that data are
no longer accidentally filtered and therefore that an error will be
raised if a key that does not match an actual field is provided.
This commit also removes the dead code that was detected thanks to these
changes.
closesodoo/odoo#81909
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Rename javascript model `mail.qunit_test` to `QUnitTest` in order to
distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81462
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.thread_viewer` to `ThreadViewer` in order
to distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81437
Related: odoo/enterprise#22911
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.composer` to `Composer` in order to
distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81327
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.message_view` to `MessageView` in order to
distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81385
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rename javascript model `mail.composer_view` to `ComposerView` in order
to distinguish javascript models from python models.
Part of task-2701674.
closesodoo/odoo#81328
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Before this commit, when a partner was created through the
suggested recipient tool the langage wasn't considered...
The email was thus sent in the wrong langage most of the time
After this commit, the suggested recipient tool had the
langage correctly if present in the record.
LINKS
Task-2580065
PR : odoo/odoo#76812
* = calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot, sms,
snailmail, website_livechat
This commit will change the declaration of the models with the aim of
getting closer to a plain JSON-object. It allows us to eliminate a wide
portion of boilerplate code, making the declaration shorter, more
declarative, and less redundant, but mainly, it prepares the ground for
further changes.
Task-2695223
closesodoo/odoo#79259
Related: odoo/enterprise#22042
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = 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>
Samuel Degueldre