On the page 'Visitors' page of the website module (backend), the cards
can be miss-aligned on small screen size. To improve the responsiveness
of the cards, we will use the `col` and `col-*` classes of Bootstrap
with some specific breakpoints (e.g. `col-sm-*`, `col-lg-*`, etc). We
will also use flex display to reduce the number of custom css rules.
task-2524363
closesodoo/odoo#73355
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves action helper message for visitors menus of
website and removes old action helper message from visitor menu
of livechat for better onboarding.
Menus
1) Visitors(action -> website_visitors_action)
Task-2584073
PR odoo/odoo#74082
Related: odoo/enterprise#20125
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The commit fixes a small UI glitch in the website.visitors kanban view when
website_livechat is installed.
Since 5a0a1e76b3
The "o_field_many2one_avatar" class works a bit differently and requires
additional wrapping.
To get around that, we specify a custom image tag with the appropriate size and
classes to get a small rounded avatar-style rendering.
Task-2612936
closesodoo/odoo#75148
X-original-commit: aa2951731458896bebfa6146a5899277b2d07e26
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
using inselect operator to inline sql in the search method and avoid ORM
to fetch multiple useless messages to check if there's one
closesodoo/odoo#70410
X-original-commit: 505c7b0946689d3ac1ac4dd2f59cf4d535c36cbb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we force messages to belong to a single document using
``model`` / ``res_id`` pair. It is not possible anymore to link a message
to channels using ``channel_ids``. A message belongs to a document and
is displayed in that document's chatter.
This change implies modifying a lot of domains, notably in chatter. Indeed
discuss for channels does not use ``('channel_ids', 'in', [3])`` domains.
They now use ``('model', '=', 'mail.channel'), ('res_id', 'in', [3])`` like
other documents fetching their messages.
This commit also removes ``channel_message_ids`` field on ``mail.channel``
model. As channels are now considered as standard documents they will use
``message_ids`` field like all other documents. Linking a channel on a message
is possible only as a link in message from now on. It is not possible to push
it into a channel anymore (no more listener channels, no more channel link).
Finally a global cleaning also linked to all previous commits is done.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
PURPOSE
Make various changes to the website.visitor views to improve readability and
ease marketing analysis.
SPECS
The changes include notably:
- Add/rename/move fields/filters elements
- Remove some unnecessary information or put it in optional="hide" in tree view
- Add website_id information (with the multi-website group)
- Slightly rework layouts (new widgets / spacing / images / buttons / ...)
- Move some technical information into the "debug mode"
LINKS
Task 2092302
ENT PR odoo/enterprise#14611
UPG PR odoo/upgrade#1902closesodoo/odoo#61417
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Also fix an issue with livechats not being considered in 'chat'
filter of messaging menu.
Task-Id 2282426
closesodoo/odoo#58468
X-original-commit: 631e52536964763bbfe857305f023e5e67084e95
Signed-off-by: Sébastien Theys (seb) <seb@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>
- Rename the 'Use Rating on Project' feature into 'Customer Ratings'
- Rename the 'Set Email Template to Stages' link to 'Set a Rating Email Template on Stages'
- Add an optional list view for the Stages menu
- display warning if the rating_template_id field is set and if one of the selected project_ids doesn't have the rating_status field set to true
- Project form view revamp
- rename the '% on tasks' stat button into 'Customer Satisfaction'
- Remove the 'no option' for the rating frequency field because it is required
- project form : Add a 'Go to Website' stat button
- Project dashboard: remove the 'Customer Ratings' menu item in more
- Ratings page: the 'Last 30 days' filter include ratings from today
- remove the Appointment / Helpdesk Customer Satisfaction / Live Support menu items
TASK ID : 1251
Some apps, once installed, automatically create a menuitem in website.
What complexify the UI and create useless menu withtout plusvalue.
It is not because you install livechat to make support online, that you want
a link in your menu to show stats e.g.
Now we remove the default menu created, and help user to find it when he create
a link. The autocomplete suggest most of the main App's controllers
task-2189613
closesodoo/odoo#49081
Related: odoo/enterprise#9733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Adds Python tests and javascripts tours on livechat (website and visitor
integration). Because breaking livechat every two days in rush periods
(or even not) is getting quite annoying.
Those tests are testing :
- The client side flow (open livechat, send messages,
send rating and close the livechat session)
- The channel and message author naming, visitor page view history
- Chat request flow (complete chat request flow, open empty operator's
chat request and cancel due to visitor's new chat session)
Task ID : 2079087
PR #40052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Lighten the survey layout. Livechat button should not appear on survey pages.
Specifications
==============
Survey Layout inherits from web.frontend_layout, mainly to be able to use all
the styles rules defined in it and keep consistency between other frontend
pages and survey.
To avoid having the livechat button displayed on survey layout, 'no_livechat'
template variable has been introduced. The livechat button will be displayed
on all layout inheriting from frontend_layout (that is extended in
website_livechat to add that livechat button) only if 'no_livechat'
is False. By default, this variable is not set so will be considered as False.
In survey layout, no_livechat is set to True.
Links
=====
Task ID: 2195185
PR #45112
In this commit we deleted tour file of website_forum beacause
of the changes applied on forum icon of new click button,
live chat icon disappear after livechat module installed and
modified livechat channel data for auto-publish channel.
task-2088546
closes#40085
Related: odoo/enterprise#6639
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>
Purpose
=======
Whenever a visitor start a livechat session but finally close the session
without sending any messages, the livechat session is empty and stay in DB.
Livechat session counter counts all the sessions (with and without message)
but when opening the sessions tree view, the view is filtered by default on
session with messages. There is no reason to see the empty sessions as it
does not give any information (except "the visitor hesitated to start
livechat and finally did not" which is quite useless info)
The goal is to keep only sessions with messages.
When the visitor is closing the livechat window, if the session is empty,
the session should be deleted. But what happens if a visitor start a livechat
session, send no message and just leave the website without closing the
livechat window ? --> empty live chat session will remains in database.
The ir_autovacuum already handle the deletion of empty sessions to main a
clean DB.
Specifications
==============
- Apply 'with messages' domain on session count in the livechat channel view
- Apply 'with messages' domain on session count in the lead view
- Apply 'with messages' domain on livechat session view
- Remove With message filter
- Remove Without message filter
- If send message on a deleted session :
just tell the visitor that operator is not available anymore
AND delete livechat session cookie (as he waited 1 day to send a message)
Empty sessions becomes invisible : not possible for users to see empty session
(in count or in views) and cron is cleaning empty sessions every day.
This commit also adapts visitor session count and view accordingly.
Task ID: 2146962
PR #41065
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit moves the import of bus JS files in the frontend assets from
website_livechat to the bus module itself.
This is done in preparation of the "survey live mode" feature that will also
require the bus files in the frontend context.
PR #43568
Task 1972640
As the percentage bar is translucid, white rating icon is not really easy to see.
Using the main rating image - red for :(, orange for :| and green for :) - is more
convenient.
Also, this fixes the height of rating chart as the bottom border was not visible when 0%.
Task ID: 2076656
PR #37511
This commit review the design of the visitor kanban view.
There is now two style for kanban card.
Ungrouped : the card takes all the width of the screen. It's simulate a nice tree view.
Grouped : Same design as before. ('normal' kanban card)
Apply visitor kanban views redesign also in :
- website_livechat
- website_crm
- website_sms
Task ID: 2073714
PR #37081
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit allows a livechat operator to send a chat request to a
connected and available website_visitor.
A visitor is considered as connected if his last tracked website.page request
was within the last 5 minutes.
A visitor is available if he doesn't have an active livechat conversation
(mail_channel with type = livechat).
- If another operator sent him a chat request
- Or if the visitor asked himself to speak with an operator
(via the normal and existing flow)
A livechat conversation is active while the visitor haven't left the conversation.
An operator cannot leave a livechat conversation, only the visitor can.
The flow to send a chat request:
- On the visitor view (tree or form), operator click on 'send chat request'
(button or livechat icon)
- A empty conversation with the visitor pops up at operator side.
- While the operator didn't send a message, the visitor won't see the conversation.
- The operator can type a message to the user
- If the operator close the chat without sending any messages,
the chat request AND the mail_channel are both deleted.
In this case, the visitor is then available to send him a new chat request.
- If the operator send a message, at the visitor's next action
(page navigation on pages that allows livechat, based on livechat rules),
the conversation will pop up at visitor side, using the livechat button widget.
The visitor won't be able to request a livechat conversation with an operator until
he leaves the chat requested by the operator.
- Once the visitor leaves (with or without rating) the conversation :
- the operator is notified that the visitor has left the conversation
- the chat request is deleted to keep the chat request table clean and minimal
- the livechat conversation if set to inactive.
- The visitor is now available again to send him a chat request.
This feature uses the already existing livechat_session cookie mechanism,
so no further code modification was needed to make this work.
It's directly integrated is existing livechat flow.
The chat_request model is only useful to quickly check if a visitor has a chat request
and to send the livechat conversation info to the visitor via the livechat_session cookie.
This commit also add a website_visitor banner info on discuss view :
To be able to quickly see all the relevant information of a website visitor
while talking with in discuss view, a fixed banner have been added.
Only the discuss view will benefit from this because detached chatter window
is to small to display such banner.
Task ID: 34624
PR #2028059
* = web, website_blog, website_crm_partner_assign, website_event,
website_event_track, website_forum, website_hr_recruitment,
website_livechat, website_partner, website_profile, website_sale,
website_sale_delivery, website_slides
The published button name is a bit ambiguous, now it will clearly state
what it does with a new title : "Go to Website". The "Published",
"Unpublished" state is shown with the globe icon changing color
(green and red) and a title on the button.
Badge and Delivery don't have a website page, the button will then be
a publish/unpublish button in the backend.
task-2002435
closesodoo/odoo#34261
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
If there is no rating for user, it will throw error while publishing channel.
This commit check if there is any rating for particular user or not.
Introduced by ce20c29f82
opw-1966384
closesodoo/odoo#32553
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
=======
Several methods of the 'im_livechat.channel' model were passed a 'channel_id' to work on.
This has been changed so that the caller can use those methods on an instance of this model instead.
Some methods have also been switched to private because they had no apparent reasons to be public.
This is a preliminary cleaning for task #1919871
Specicial note for the "loader" template:
To load the livechat assets in a website page, the 'loader' template of livechat
is directly called (instead of being returned through a controller) in order
to avoid a new call to server.
As this commit moves 'sudo' to make method callable on the record directly, it
still needs to be sudo. First solution was to add the 'sudo' in the template, which
is a bad practise.
This commit creates a proxy method on website model returning the livechat info
with 'sudo'. This avoid having the 'sudo' done in template. Like always, explicit
is better than implicit.
Task-1919871
The utility classes `Timer`, `Timers` and `CCThrottleFunction`
were only used by the feature 'is typing...', thus all those files
were in the same folder.
This commit moves the utility classes in a dedicated folder,
and introduces a folder for thread mixins, in preparation for
future features on threads that will be implemented as mixins.
To avoid that people know the complete name of the support members
(for privacy purpose), a username can be used.
Users have the opportunity to set and modify their username in
their user preferences.
If the username is not set, the complete name will still be used.
If the username is set, it is used for the discussion title, the
name of the message sender, the name of the team members in the
channel statistics. All of this, only in the livechat context.
Task ID : 1895998
Closes PR #28283
This commit adds more precision about ratings per operators for a
specific channel. Only the operators that have been rated on the last 100
feedbacks have their statistics displayed. The other operators that did not
worked (or have not been rated) on the last 100 feedbacks are still displayed
but are flaged as 'Not rated yet', so we still can see who is working on this
channel.
Task ID : 1895998
Closes PR #28283
Before this commit, when changing the website field in a record form view,
the is_published field would be force to false, ending unpublishing the record
if it was published.
That behavior was coming from the fact that is_published field is missing from
the form view. Thus, onchange on website is triggering a recompute server side
without is_published as the JS framework is not sending the field.
The ORM is then fallbacking on default Boolean value (False) for is_published
when sending back the onchange result.
This would only appear on object with 'website.published.multi.mixin' and with
website_id in the form view.
Replacing website_published by is_published will fix the behavior and has more
sense has website_published is the 'is_published' state in a website context.
In the backend, we are not in a website context.
task-1919689
- Add a method for generating an image data URI, and expose it in QWeb context
- Fix reports, website templates or mail templates with data hardcoded
data URIs, to use the helper (Python cases), or the existing
kanban_image helper (for JS cases)
This will gracefully handle SVG support in addition to classical image
formats.
Closes#26635
Future update will allow to save oe_structure editions in an inherited
view instead of editing the original view in place. The condition is
to have an id on the .oe_structure element which contains the
'oe_structure' string.
The statistic bar size is now related to the value of the rating
+ Adds small modififications to align correctly the different divs
+ harmonize icons size
+ show white icon for readability
+ Add inline padding to team member icon for readability
(inline because this part will be completelly reviewed in next version)
Task ID 1883227
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
With this commit, most threads show an indicator when a member is typing
something. e.g.
"Mitchell Stephens is typing..."
Supported threads:
- DM
- (public & private) channels
- Livechat (Website & Backend)
Unsupported threads:
- mailboxes (e.g. 'Inbox')
- document thread (= 'Chatter')
- support channel (with `im_support` module)
Some technical details:
- This is a mix between 'start'/'stop' and 'regular notify' strategies.
- On typing text in composer: notify 'start typing' to all members of
thread.
- On clearing text in composer: notify 'stop typing' to all members of
thread.
- A member can only notify once every 2.5 seconds to the server when he
starts or stops typing something (throttled, buffered notify call).
- On receiving a message from someone that is typing: determine that he is
no longer typing.
- On non-empty and unchanged composer text for 5.0 seconds: automatically
notifies all members of thread that he is no longer typing anything.
(This is like a 'soft / cooperative sender' timeout).
- On non-receiving a typing notification of someone after 60 seconds:
determine that he is not longer typing something (This is like a
'hard / receiver assumption' timeout).
- When some types for more than 50 seconds straight: notify that he is
still typing something (again and again every 50 seconds).
- When two or more people are typing something (Multi-User channels), it
displays at most 2 typing users (ordering rule: longer typers first):
"Mitchell Stephens, Marc Brown and more are typing..."
- Timing summary:
- Usually 2.5 seconds uncertainty.
- Up to 5.0 seconds uncertainty on typer inactivity.
- Up to 60 seconds uncertainty on typer page reload / browser tab
closed / etc.
Future Improvements:
- Detect page reload or browser tab close with loose of longpolling
connection
Task-ID 28188
The purpose of this change is to make the code clearer and testable.
In this change, the 'tab_manager' static object was merged with the bus
cross tab.
Cleaning was done to clearly define private and public functions as well
as handlers. The methods are documented and the constants are now defined
on the class. The bus use the service behavior with 'trigger_up'.
'bus.CrossTab' who extend 'bus.Longpolling' are instantiated by the
bus service.
The class is always instantiated with a parent, or root in the case of the website
(im_livechat), to use the ajax and localstorage services. So the behavior, perhaps
logger or redefined by the parents.
Only two classes remain to declare a media structure:
'media' and 'media-body'. 'media-left/right' are guessed by their
position using the flex layout.
Also, the 'media-list' class has been dropped but <ul/> element
should use the 'list-unstyled' class instead.
Like all other components, spacing between medias are now to be
handled explicitely thanks the spacing utility classes.
Julien Banken