ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
This commit applies the following ACLs rules:
C : nobody can create visitor (except system)
R : everyone that should access to this model
U : website_designer can update (even if only few fields are editable),
mainly useful for language (+ system obviously)
+ livechat users as they are the guys who directly speaks with the visitors
D : system + website_designer can delete, mainly useful to clean if necessary
Remove the no_create from all visitor views as handled by ACLs.
This fixes the 'can create' that should not be done by any users
except system + admin
Task ID: 2092502
PR #40439closesodoo/odoo#40865
X-original-commit: 23f3324830adf31edb0a12c7009fcb65b0f54614
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
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
Migrate the models and controller to new API. Renaming xml id according to convention, renaming openerp tag into odoo tag. Add comment strings and documentations.
Victor Feyens