Steps to Produce:-
- Install `Advanced Events`
- Go to ` website` then `Configuration`
- Open `setting`
- Then change favicon and Select svg type file and click on save
- Traceback is here
Cause :-
- The traceback occurs when an SVG image is passed to the ImageProcess method.
In this scenario, the method sets the image as false, and then attempts to
access its size, resulting in the traceback
Fix :-
- The issue has been resolved by implementing a condition check for the image
before accessing its properties. This ensures that the image is valid before
trying to retrieve its size, preventing the traceback from occurring.
sentry-4199175498
closesodoo/odoo#127958
X-original-commit: ebb1e89b367dced4a2157751de12a53bf41ae400
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
PURPOSE
Visitors are useful in terms of marketing analysis but they can bloat the
database really quickly if you have a lot of traffic on your website.
This commit aims to relieve the database by fully deleting inactive visitors.
SPECS
On an active website, you can easily reach hundreds or even thousands of
visitors per day.
While active visitors are useful for marketing purposes, inactive ones were
archived after a period of inactivity (i.e: not connected for X days in a row,
where X is configurable as a parameter and 30 by default).
But archiving visitors is not really useful either.
We don't see any specific cases where you would want to restore some visitors.
That means we are better off unlinking the visitors completely to save database
storage space.
We want to make exceptions and avoid deletion of inactive visitors in some
cases:
- When they are linked to a partner (meaning most likely linked to a
registered user)
- When they are linked to leads
- When they are registered to events
Several tests were added to ensure that leads matching these conditions are not
unlinked.
We also took this opportunity to enforce the "_link_to_visitor" rules in those
tests to make sure that:
- When visitors are linked, the leads are merged into the main visitor
- When visitors are linked, the event tickets are merged into the main visitor
- When visitors are linked, the wishlisted tracks are merged into the main
visitor
This is also preliminary work for a commit that will move the push_token of
website.visitors to a separate table.
That will in turn allow us to link the push_tokens within the
"_link_to_visitor" method and delete the linked visitor instead of archiving
it.
LINKS
Task-2410217
Part-of: odoo/odoo#65113
Purpose is to have a common event class for users and useful stuff (customers,
products, ...) but lessen usage of common test data through sub modules.
Indeed having a "global event type" test data updated in various addons is
actually complicated to maintain.
Sub add-ons are updated to use mainly the ``EventCase`` test class holding
users and side data. Data specific to those modules (event type with some
specific configuration notably) is created and used in tests in the given
module only, and not through generic event_type_complex and event_0 test
data anymore.
With this commit tests are more localized to their add-on and modifying data
in a given add-on has less chances to have unwanted side effect in other event
submodules unit tests.
Task-2703285 (Event performance improvements)
Task-2703289 (Event testing and coverage)
Part-of: odoo/odoo#81068
In website_event some event-specific frontend menus are not linked to
``website.event.menu`` like track or exhibitor sub-modules menus. This
comes from initial implementation of ``website.event.menu`` that was
available only for ``website_event_track``.
Using ``website.event.menu`` eases menu management as it allows to have
an object making a link between the event and the website menu. Notably
when checking / unchecking in backend submenus it eases management.
It also eases management when people manually edit menus from frontend
as otherwise we have to manually manage ``ir.ui.view`` based on some
naming manipulation.
Task ID-2577079
See odoo/odoo#72411
Distinguish and display to the speaker which info is collected by the form
for internal use vs external dissemination. The contact details one wants to
share with the event manager (Private details : contact_phone, contact_email)
could indeed be different from the ones shared to attendees (partner_phone,
partner_email,...). The form in both back-end and front-end is made more
detailed, including more fields. Previously the form could have several
speakers, now only one.
Front-End
- Track proposal form changed, now includes tags, contact / speaker info...
- Track name and description are mandatory fields
- User can select (but not create) several track tags from those existing.
This allows categorizing the track in pre-defined categories with format
"tag category : tag name". It requires a select2 widget,
implemented in new file website_event_track_proposal_add_tag.js.
- New tickable section "contact me through different contact" not displayed
if the checkbox is not ticked. If the section is ticked, then the info set
there (contact_name, contact_phone, contact_email) will be added on a new
contact with id partner_id set on the track.
- In both cases (checkbox on/off), if the contact/partner email is the
same as logged user's, uses its partner on form. No contact creation needed.
- Improved / dynamic error display on form submission. If the form is valid,
it resets after submission.
- New widget in website_event_track_proposal.js:
- The partner_name is propagated on contact_name on input but editable.
- When the optional section is checked:
- The contact_name is made required.
- The user must at least enter a contact phone or an email. The email
is normalized but any phone format is accepted, since the choice of
country is not resolved (e.g. geoip not always relevant). Could be
improved with international phone number widget, see COM PR #34725
Back-end: following changes are done to ease contact creation and form completion
from back-end, as well as reaching the speaker from chatter
- On the form:
- If created on the fly from M2O (entering a name and using "create ..."),
the new partner will use default values contact_phone and contact_email.
- Once the contact is set (partner_id), contact_phone and contact_email
are set to readonly since they change according to the partner.
- When setting or changing the partner: this will fill all the form fields
with new available partner data to ease the flow, but only the empty ones
(this prevents losing previously entered information).
If partner is a company, company name is set to the name of partner.
- All fields are editable in the speaker section.
- Exception thrown if no contact mean available when supposed to.
- On the chatter, about contact creation and message subscription:
- From contact creation through suggested contacts.
- If the partner is set but is not in the followers, it is suggested
- If no partner is set, then there is at maximum one suggested contact
from track data: using contact_email if there is one, partner_email
otherwise. This priority serves main commit purpose. The user can
create and edit a corresponding contact if the address is not linked
to a partner. It will then be searched for and set on track.
Modifies tests in test_track_partner_sync. Before, partner fields on track
would be erased by customer's ones. Now, they are updated only if empty.
Contact fields are erased by customer's ones if set. tests changed accordingly.
Task ID - 2329406
COM PR odoo/odoo#60847
UPG PR odoo/upgrade#2346
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Stored editable fields receive their values either from compute either from
user input. If a user input is given to create / write compute method is not
called. If multiple fields are computed through the same method giving one
field value discard call to compute method and other fields are not called.
SPECIFICATIONS
Split ``_compute_parnter_info`` compute method so that partner related fields
are independent.
LINKS
COM PR #65688
Task ID-2455165
X-original-commit odoo/odoo@12d7aae9ee
X-original-commit: 436fb7d7aa339e86753721d3385df4f4517d2d30
Add tests related to registration / partner contact fields synchronization.
Add tests with user input and/or partner synchronization to ensure editable
stored fields work as expected on registration model.
Add tests related to event track / partner contact fields synchronization.
Add tests with user input and/or partner synchronization to ensure editable
stored fields work as expected on track model.
Add tests related to event / event type configuration fields synchronization.
Add tests with user input and/or event type synchronization to ensure editable
stored fields work as expected on event model.
Warning: those tests are currently partly failing. Next commits will split
computed fields into several methods in order to fix computation.
LINKS
COM PR #65688
Task ID-2455165
X-original-commit odoo/odoo@6b0346bbb5
X-original-commit: 7f0c7339c39b05e20efa163d0ea91f7dd5c0017c
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Merge website_event_track_exhibitor into website_event_exhibitor and remove
dependency on website_event_track. That way all features related to sponsors
are now located within website_event_exhibitor.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Move everything related to event.sponsor model from website_event_track
to website_event_exhibitor. Functionally feature should be the same as
before except that we should be able to configure and display sponsors
directly with website_event_exhibitor application without using tracks.
Website_event_exhibitor should also define the sponsor template used to
display sponsors below an event.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
This commit adds a website-specific and customizable app name for the
Events' Progressive Web Application, configurable through the website's
settings.
Defaults to '<website_name> Events'.
closesodoo/odoo#56564
X-original-commit: 423076ddf1da0fc61d9a18dc19bbbbf900e3dad6
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit fixes glitches when switching menus. Indeed agenda is not correctly
taken into account, meaning it could get duplicated. Moreover track was
constantly coming back as True event when not wanted.
Behavior is: when setting website menu, force it to True, otherwise let users
defined its value. Agenda is part of track menu so fix its declaration in
_track and _track_online methods.
Task ID-2314778 (event online fixes)
PR #56340
PR odoo/enterprise#12589
X-Original-PR #56254
X-Original-Commit odoo/odoo@5821758c4d
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_track.
SPECIFICATIONS
Move all content of website event track session to website event tracK. It
was mainly of rewriting of views and can now be safely merged into the base
track module.
Update dependencies accordingly.
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_track.
SPECIFICATIONS
Move remaining content of website event track online to website event track.
Agenda notably is completely replaced by the new one developed within
track_online module.
Update dependencies accordingly.
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_track.
SPECIFICATIONS
Move website event menu model directly into website event. Website event menu
model has been introduced to help dealing with event-specific menus and
website menus. This is some kind of glue to synchronize both of them as people
could either
* update an event (website_menu, website_track) that updates website menus
availability;
* update menus through website that should update event field value and menu
computation;
Having a model introduced in website event track forces to have override and
code split across website_event, website_event_track, and now also in both
_online version of those two as menu management was improved.
In this commit we simplify all this code by moving most of menu management
code in website_event, leaving only business-specific code (fields and their
menus) to sub modules.
SPECIFICATIONS: WEBSITE EVENT MENU
Make type required as we don't support entries without type. Indeed this model
is used to automate menus generation / destruction, and not for hand-made
menus. We therefore set type as required and add a cascade ondelete for
selection.
SPECIFCIATIONS: COMMUNITY MENU
Doing this change allows to define community menu in website_event and re-use
it in website_event_meet and website_event_track_quiz, removing some
unnecessary dependencies. This menu is void in website_event, and displays
either meeting rooms (in meet) or quiz points leaderboard (in quiz), or a
mix of both if the two features are installed.
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#165
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
New and improved pages are about to land for online event. However current
menus and pages management is hard to tweak, especially when dealing with
the stable policy of 13.3 .
SPECIFICATIONS
Refactor and improve code about event menu management. Purpose is to
ease inheritance and be able to add menus and pages with less custom code
in sub modules.
Refactor some code, notably
* code dealing with menus to activate and de-activate that is duplicated
for each kind of menu;
* allow to give a menu_type through inheritance in create_menu notably to
support website.event.menu model available in Track app and unfortunately
not in website_event;
* make a somehow generic way of getting fields dealing with menu items
through simple inheritance;
* support sequence to allow ordering of menu entries by propagating the
sequence to website menus;
Behavior in website_event and website_event_track should be the same. Behavior
will be tweaked in other modules through inheritance..
Improve behavior when removing frontend menus
* correctly fetch views (for Introduction / Location) and try to unlink them
to avoid bloating the db;
* update boolean menu fields according to website menu management. Removing
a menu from frontend should be reflected on boolean fields of event;
LINKS
PR #55260
Task ID-2310491 (Event Online Preparation 5)
Part of Task ID-2252655 (Main Online Event task)
Part of Task ID-2283796 (Event B2Basics / Registration Flow)
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
Even 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., ...
SPECIFICATIONS
Improve website_event and website_event_track test coding style, notably
* use specific users when performing tests to trigger access rights issues
(this notably allowed to find an issue with event groups not allowed to
update menus);
* define common classes;
LINKS
PR #54801
Task ID 2304817 (Event Preparation 3)
Prepares Task ID 2252655 (Main Online Event task)
Prepares Task ID 2283796 (Event B2Basics)
X-original-commit: 774211c7e4667c5350ac090510e72c106f2d10b6
Before this commit, the website menus were created only on write on an event
After this commit, the menus are created at create time too
OPW 1914343
closesodoo/odoo#30919
Adesh Jolhe