Aliasing the fields in the select clause of the task report allow to do joins latter when inheriting from this object without getting ambiguous fields errors.
related task 2009563
This commit move some code to be able to override
Bootstrap popover in web_enterprise for mobile.
Task ID: 2052506
closesodoo/odoo#35727
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This merge adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's useful to see his last page views.
If a website_visitor submit a contact form (and becomes a lead),
the website_visitor is linked to the crm.lead.
If a website_visitor logs in,
the website_visitor is linked to the user's res.partner.
This also allows a livechat operator to send a chat request to a
connected and available website_visitor.
See sub commits for more detailed informations about functional flows
and technical changes/decisions.
Task : https://www.odoo.com/web?#id=2028059&action=327&model=project.task&view_type=form&menu_id=4720
Linked to enterprise PR odoo/enterprise#4834closesodoo/odoo#34624
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since introduction of website_visitor,
we don't need to identifiy the lead with a lead_id cookie.
The visitor is identified and if a lead is created with the
contact form, the lead is created and linked to the visitor.
To avoid losing data, each time a visitor send a contact form,
it creates a new lead. All those leads are linked between them
via the website_visitor.
As the website_visitor already has the lang set on itself,
there is no reason to keep the lang_id of crm_lead at enterprise
side. So that lang_id on crm.lead has been moved to community.
This commit is directly linked to another one in enterprise
See https://github.com/odoo/enterprise/pull/4834 to get more details.
Task ID : 2028059
PR #34624
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
If a website_visitor submit a contact form (and becomes a lead),
the website_visitor is linked to the crm.lead.
the website visitor name is than adapted to match the name of
the first crm.lead linked to the visitor, ONLY if the visitor doesn't
already have a res.partner.
A visitor can have multiple crm.lead as he can send multiple
contact form and create multiple leads.
Task ID: 34624
PR #2028059
This commit adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
- A website_visitor is created once the visitor is requesting
a website.page that is tracked.
- A website_visitor is considered as connected if his last tracked
website_page request is within the last 5 minutes.
- The number of visits for a website_visitor is incremented
if his last tracked website_page request was at least 8 hours ago.
- A website_visitor is only handled by the system. Users cannot
create, edit or delete a website_visitor.
- A unique website_visitor is created per website.
That means that the same real person can triggers multiple visitor
creation if visits multiple websites.
This is because, for livechat purpose on later commit, for example,
the chat request can be created on the correct livecaht channel
(linked to the correct website)
- The visitor is recognized via his cookie (visitor_id). So if the visitor
flush his cookies, a new visitor will be created the next time he will
request a tracked website_page.
- Link user's res.partner to website.visitor.
If a website_visitor log in
(a visitor that has visitor_id in his cookie),
the website_visitor is linked to the res.partner.
The website visitor name is than adapted to match the name of
the first res.partner linked to the visitor.
A visitor can have multiple partners as the same session
can be used by multiple person (one PC for a team for example).
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's usefull to see his last page views.
Task ID : 2028059
PR #34624
When create a return from a delivery order, the field `to_return` must
be True, so the delivered quantity of the sale order will be updated by
default. But it wasn't the case before this commit !
Thus, adds a test to be aware in the case something goes wrong again.
Task #2050183closesodoo/odoo#35733
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The purpose of this commit is to expose SEPA Direct Debit acquirer to
the Odoo community edition. The dedicated module, though, is restricted
to the enterprise edition.
Minor changes in following modules:
- base: added ir.module.module record
- payment:
- added data to expose the new payment acquirer.
- added 'to_buy' field to track whether the payment acquirer is
restricted to enterprise users.
- allow multi word payment acquirer name. It was breaking on the first
underscore.
task-1870363
closesodoo/odoo#26427
Follow up of 3620cb68a0
`split` called on an empty string returns a list containing the empty string.
The previous commit assumed it was returning an empty list.
closesodoo/odoo#35773
Signed-off-by: Christophe Simonis <chs@odoo.com>
For better user experience, there should be a 'UPLOAD' button on'hr.expense'
through which user can directly upload a single or multiple documents and
according to the number of documents, blank expense record with attached
document should be generated. These records should be in 'draft' state.
TaskID: 2040887
closesodoo/odoo#35400
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Enable invoice management from sale order in all modules having sale as dependency.
closesodoo/odoo#35658
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The Common partner contact setting is removed from general settings because its
behavior wasn't really clean from a technical point of view
(disabling the rule on partner access) and wouldn't work as well with new
multi-company logic.
The default logic of sharing partner will be kept, but when someone wants to
limit partner sharing, he will do so partner by partner, by
setting the company_id.
Also, the default company_id on a partner will be blank so default partner
will be a sharable by multi-company.
when the partner is created at the time of user creation then the partner's
company will be the same as user's company.and when the partner is created at
the time of company creation(partner related to company) then the company of
partner will be newly created company.
task-2024446
Closes: #35266
After editing multiple record, we want don't want any
record selected. This commit ensures that.
closesodoo/odoo#35678
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Fixed crashes/incorrect behaviours in multi edition in the list views.
The solution to these problems was mainly to refactor the function
used to save multiple records.
Before this commit:
- Cancelling the confirmation dialog in multi edition caused
the edited record to be editable but disabled
- Saving an empty field in multi edition triggered a JS error
- Static confirmation message ("saving 0 valid records")
After this commit:
- Ability to cancel confirmation
- Proper error display when trying to save empty fields
- Message consistent with the situation
Adding a line in grouped listviews caused a crash in some cases.
Steps to reproduce:
- go in any grouped editable list view
- click on any "Add a line" cell, but not on the link itself
- press ENTER
Before this commit:
A crash occured. Unable to add a new line. Needed to refresh the page.
After this commit:
Line addition functionnality properly working even when selecting the outer cell
In this commit:
- removed an unused event handler
- fixed an overriden variable used in a subfunction
- fixed a variable mismatch
No bug was induced by these issues until now so it doesn't impact
any behaviour. This is just an extra security for the future.
Pressing ENTER on a button element triggers an additionnal 'click' event.
Since this 'unwanted' click caused some issues in a few cases, we prevent it.
Moreover, there isn't currently any known case in which this event is useful.
Before this commit:
No modification of the initial behaviour on ENTER key
After this commit:
ENTER key pressed in abstract fields has its default behaviour suppressed
Before this commit, there was a slight offset preceding list selectors,
and the red border of invalid fields was not shown in community.
Now list selectors are correctly displayed as well as invalid fields.
Added an option in the Dialog class to give it a function to run
when it's closed by other ways than by its buttons.
Its default value is the "cancel" callback if given, or none.
Before this commit, there was no way to add any callback to run
when the modal wasn't closed by a button.
Now, when exiting the modal by other means (e.g.: "Escape" key),
it will run a given callback.
This change allows direct keyboard navigation between the current action
searchbar and renderer.
Focus can now be toggled using DOWN arrow when focusing the searchbar
or the UP arrow when focusing the top cell/record of a kanban or a list.
MaxLarue