Applies various improvements:
- Remove welcome message if chat request usecase.
- If a visitor is online: line is green / if offline: line is red (in the list view)
- Visitors list view: add first / last connection fields and remove time_since_last_action
- Avoid useless leave notification if the livechat channel is empty
Fix
- ACLS on website_visitor_page model (for im_livechat_group_user)
- ACLS on website_visitor and website_visitor_page model (for sales_team.group_sale_salesman)
- Update visitor lang if visitor change the website lang.
- Create visitor twice when translated website (due to rerouting)
- Avatar for visitor banner in discuss. (image_64 instead of old image_small)
Task ID: 2056080
PR #36290
When a visitor close the livechat and submit a review,
the "Send" button is not styled.
closesodoo/odoo#36487
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when using website livechat with multiple tabs,
it may duplicate messages in the chat window.
This happens due to registering messages twice:
- once, from `/mail/chat_history`
- second, from receiving notification from master tab, via local
storage.
This commit fixes the issue by not registering messages that have
already been registered (i.e. unique ID).
opw-2052960
closesodoo/odoo#36370
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Open a livechat session between a visitor and a user
That is, open the / controller as public user, and click,
on the bottom right corner, on "Have a question ? Chat with us."
Exchange at least one message to open the session
From the visitor side, close the window. There is a proposal to rate the discussion
Assign either the green face or the yellow one
(The red one is a bit trickier)
Now, on the user side, check the list view of LiveChat sessions
Before this commit, the rating of those sessions were 0
This is because:
The rating.rating < Many2One > mail.channel link is not a foreign key
(rather, it is composed by char::res_model; Integer::res_id)
and doesn't make the reciprocal field recompute, which in turn doesn't make
our relevant field compute
After this commit, the last_rating field field is recomputed and appear in the list view
OPW 2052964
closesodoo/odoo#35830
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.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
What was going on here is that when the operator start the discussion with the visitor
and the visitor navigates to a new page, the livechat button widget checks the
cookie and see there is already a active conversation.
It loads the mail_channel and write all the history of the conversation.
So the first message is writting a first time.
Then, it handles the notifications. As the visitor did not receive the
first message notification yet, the first message notification comes up
and the widget handle it. Adding the message a second time.
To avoid this, we just stop the notification handling
if the message is already present in the conversation.
Task ID: 2028059
PR #34624
after this commit user can get a copy of the conversation with operator
task-2029660
closes#34620closesodoo/odoo#35083
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Improve the usability of the employees profile / "My Profile"
TaskID: 2048672
closesodoo/odoo#35587
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
A previous commit modifies the way in which
date filters work in the Filters menu.
In particular, the attribute default_period of filters
with date attribute cannot take anymore values
like 'this_week', 'last_7_days',...
This commit modifies the xml acoordingly by replacing
the attributes date and default_period by a suitable
domain.
Task ID: 2028787
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
The big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
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