* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The images of users in the livechat team were overlapping
with their ratings on the front-end page of the livechat channel.
Remove negative gutters to fix this.
task-3135733
closesodoo/odoo#112661
X-original-commit: 619a39e2f1fe50f5c76f2b54a578598e1540ef8d
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
*: website_blog, website_event, website_forum, website_links,
website_livechat, website_slides, survey, web_editor
This commit removes the website navbar root widget, as the edition is
now handled in the backend through the client action and custom menus.
It removes associated widgets and their css.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides,
website_slides_forum
The goal of this commit is to add dialogs to create new website content
using a 'target:new' action on the form view and an overridable
"website" form controller.
See merge commit for more information.
task-2687506
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
PURPOSE
This commit introduces a chatbot operator that works based on a user-defined
script with various steps.
SPECS
A im_livechat.chatbot.script can be defined on a livechat rule.
When a end-user reaches a website page that matches the rule, the chat window
opens and the script of the bot starts iterating through its steps.
The chatbot code is currently directly integrated with the existing livechat
Javascript code.
It defines extra conditions and layout elements to be able to automate the
conversation and register user answers.
AVAILABLE STEPS
A script is defined with several steps that can currently be one of the
following types:
"text"
A simple text step where the bot posts a message without expecting an answer
e.g: "Hello! I'm a friendly robot!"
"question_selection"
The bot will ask a question and suggest answers, the end-user will have to
click on the answer he chooses
e.g: "How can I help you?
-> Create a Ticket
-> Create a Lead
-> Speak with a human"
"question_email"
That step will ask the end user's email address (and validate it)
The result is saved on the linked im_livechat.im_livechatchatbot.mail.message
"question_phone"
Same logic as the 'question_email' for a phone number
We don't validate the input this time as it's a complicated process
(requires country, ...)
"forward_operator"
Special type of step that will add a human operator to the conversation when
reached, which stops the script and allow the visitor to discuss with a
real person.
The operator will be chosen among the available operators on the
livechat.channel.
If there is no operator available, the script continues normally which allows
to automate an "answering machine" that will redirect the user in case no
operator is available.
e.g: "I'm sorry, no operator is available right now, please contact us by email
at 'info@company.com', we will try to respond as soon as possible!".
(Or even something more complex with multiple questions / paths).
"free_input_single"
Will ask the visitor for a single line of text.
This text is not saved anywhere else than in the conversation, but it's still
useful when combined with steps that create leads / tickets since those print
the whole conversation into the description.
"free_input_multi"
Same as "free_input_single" but lets the user input multiple lines of text.
The frontend implementation is made by waiting a few seconds (currently 10) for
either the next submitted message or the next character typed into the input.
This lets visitors explain their issue / question with multiple messages.
Which is very useful since new messages are sent every time you press "Enter".
LINKS
Task-2030386
Part-of: odoo/odoo#84000
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
The concept of 'parent_id' on website.visitors was introduced in the saas-13.3
stable while implementing the "event online" feature:
However, it should have been part of the website module from the start since
it's a 'global' concept that does not depend on events at all.
See #53540 for more details.
This commit aims to clean the code by moving the field to the website module,
which allows a nice cleaning of associated overridden methods as well.
Along with that, we move the website.visitor demo data from the event module to
the website module, allowing a fresh install of website to showcase some of our
visitors feature.
We also took this opportunity to do some minor improvements in the visitors
kanban view in order to make relevant information more visible.
Task-2429652
Part-of: odoo/odoo#65113
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
Sébastien Theys