RATIONALE
Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...
PURPOSE
Ensure to have a visitor when people registers, in order to enable wishlist
or notifications. Improve visitor model to keep information when people change
device.
SPECIFICATIONS: REGISTRATION FLOW
This commit ensures a visitor is created when a registration is done on an
event. Creation is done only if a visitor does not already exists like all
visitor-based flows.
In case of multiple registrations made by the same visitor, only the first
registration is linked to the created/existing visitor. We take the opportunity
to update the visitor's information based on the registration's infos.
We also add some fields to get all visitors from an event, based on visitor
and registration link. This could be used for example to contact them, like
sending a mailing or push notification to all attendees of an event.
SPECIFICATIONS: VISITOR LOGIN / INFORMATION UPDATE
When a user is linked to a visitor (e.g. when customer logs in) its partner
is propagated to the registration. Using visitor as middle-model it allows
to propagate information through those models, leading to better contact
data notably.
SPECIFICATIONS: VISITOR IMPROVEMENTS + PUSH TOKEN
In this commit we improve visitor behavior. Currently when there are several
visitors that may be linked to the same user, only the last one is kept and
other one are unlinked.
However visitor model holds push tokens, allowing to store approval for push
notifications. Unlinking records is therefore a bad idea as we may loose
information. In order to solve this an intermediate solution is implemented.
A new parent_id field is added on visitors. Instead of unlinking "duplicates"
we link them to the parent and de-activate them. This means more visitors
are present in database, but this is required to keep push tokens.
A better solution would probably be to separate visitor from push tokens
but as this merge targets a stable version it was difficult to do in a clean
way.
LINKS
Community PR #53540
Enterprise PR odoo/enterprise#11384
Task ID-2252655 (Main Online Event task)
Task ID-2283796 (Event B2Basics / Registration Flow
Task ID-2284043 (Visitor-based track wishlist)
Task ID-2283869 (Notify attendees by push)
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
RATIONALE
Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).
PURPOSE
Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online.
SPECIFICATIONS
Add anchor methods to somehow merge visitors and update partner linked
to visitors and their sub records.
Main idea would be to be able to
* avoid unlinking visitors, notably because we have keys linked to them
allowing push notifications. As a given user may be linked to several
devices (different keys / different visitors) keeping them in database
improves push efficiency;
* allow to link sub-records to a main visitor, like tracked pages history,
even if multiple visitors are linked to the same identity;
In this stable we cannot remove current unlink of duplicate visitors due
to constraint of partner_id / visitor_id. However those methods allow to
tweak behavior by override. This will be done in future tasks.
LINKS
Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036
X-original-commit: 8a8d2d4412d1b58545ee4f0240cca5114e541b6a
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
RATIONALE
Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).
PURPOSE
Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online.
SPECIFICATIONS
Introduce a new configuration parameter in website allowing to set number of
days before de-activating visitors: ``website.visitor.live.days`` . It is
set to 30 days instead of 7 as before.
Purpose of extending delay is to be able to use visitor information a bit
longer in business flows. For example one could contact visitors 2 weeks
after an event to get their feedback. Adding a bit of delay allow to keep
those visitors alive a bit longer by default. Allowing to configure it gives
more flexibility to admins and deployment.
LINKS
Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036
X-original-commit: f83af1d53716499dcad94f363aff609a2f8e55d9
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
RATIONALE
Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).
PURPOSE
Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online.
SPECIFICATIONS
Make tests independent from existing database data, notably existing visitors.
Use newly-introduced tools and data. Clean tests and make them easier to
understand, notably connection / disconnection effects. Make more tests about
visitor data: name, partner_id, tracks move from visitor to authenticatedf
visitor, ...
LINKS
Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036
X-original-commit: 015f70dd1ce1394d279f8fbb949948f4845c65fc
RATIONALE
Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).
PURPOSE
Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online
SPECIFICATIONS
Clean existing visitor tests. Use HttpCaseWithUserDemo and clean bootstrapping
of data.
Introduce a mock for visitor from request allowing to shortcut some visitor /
user synchronization and test directly expected results without too much
boilerplate in tests.
LINKS
Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036
X-original-commit: 4e0d4e7c315b5a9d880754e02966debd6a59c728
visitor.partner is a many2one to partner. But partner.visitor_ids is a
many2many.
The result is when you set the partner_id on visitor, the (what should be)
inverse field is not set accordingly.
This inverse field should be a one2many fields. This commit fixes the field
definition.
Task ID: 2127691
PR #40577
Related: odoo/upgrade#905
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a visitor logs in (and has a visitor_id in his cookie), the partner will be
linked to the visitor. If, after 1 week, the visitor tries to connect again
with a different session (or another visitor_id in cookies), the authenticate
will crash because
* _cron_archive_visitors applies on visitor inactive since at least a week
* there can be only one visitor per partner (sql constraint)
* the visitor linked to the partner is not retrieved (because archived) and
we try to link the partner to a new visitor.
Further than that, if the visitor is archived and the linked partner wants to
login again with a new visitor_id, we should
* reactivate the previous visitor,
* copy history from newest to previous one,
* delete the newest one
Note that last two points were already done before this commit.
Task ID: 2120464
PR #40199Fixes#40077Fixes#40301closesodoo/odoo#41273
Original-signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
X-original-commit: 53a6bed3b5c1ae09be490254ed09f18acbb970c4
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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
