*: website_event_booth, website_event_exhibitor, website_event_track
Before this commit, when no events (or exhibitors, tracks,..) were
displayed for the user, only a title (eg. "No events found.") was shown
to them.
Now, it will display an illustration (color adapts to theme's color)
alongside more information:
- title
- call-out
- call-to-action for editors (add event, tracks, exhibitors..)
task-2489681
closesodoo/odoo#107638
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit changes the way the identification questions (name,
email, phone) are asked when registering to an event. They aren't
hardcoded anymore and can be created per event the same way other
questions can be. They can be set as mandatory or not and the order
can be changed. One can now also ask for the attendee company name.
Task-3056380
closesodoo/odoo#112164
Related: odoo/upgrade#4313
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit moves the code from website_event_questions to
website_event and from website_event_crm_questions to
website_event_crm module.
Task-3056380
Part-of: odoo/odoo#112164
*: website, website_blog, website_event
This commit adds the TikTok social network to the other social networks
stored in DB. Thus, users of the Website application will be able to
reference their TikTok page on their websites. This commit also updates
the different templates and the social media block to integrate this new
social network.
task-3235451
Part-of: odoo/odoo#116837
This commit follows the addition of the OWL date picker and intends to:
- update views calling daterange widgets to use the new syntax (and
remove the end date field from the view in most cases);
- change the remaining components extending the previous DatePicker and
DateTimePicker components.
Part of task 3121497
Part-of: odoo/odoo#112171
*: mass_mailing, website_blog, website_event, website_mail_group,
website_mass_mailing, website_payment, website_sale, website_twitter
The names of snippet blocks are not translatable because their name is
obtained from a their template name which is not a translatable item.
For markets that use a non-latin alphabet this is a no go.
This commit makes it possible to specify a `string` attribute in the
`t-snippet` blocks that makes their name inventoried by the translation
process.
closesodoo/odoo#118530
X-original-commit: a501d226d8674ed0c9b183c69a9e754c79682237
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer
have a relative positionning. As a result, most elements having an absolute
position and placed relatively to those elements will be incorrectly placed.
In website_event, the badges of the event cards are currently placed on
the upper border of the card because they are now placed relatively to
the whole card instead of the card body container having a `col-*` class.
As a result, the badges isn't where it should be and get cropped by the
container.
Steps to reproduce the issue:
1. Create a new event
2. Set a template
3. Go to the /event page
4. Click on the edit button from the Odoo navbar to edit the page (editor)
5. Go to the "Customize" page
6. Click on the "Templates" toggle button
To fix that issue, we will add a `position-relative` class on the card
body container having the `col-*` class. This ensure that the badge will
be placed as before between the card body and the card image.
task-3251110
closesodoo/odoo#117872
X-original-commit: 08f98194c095c541bf24d8ba55b440b189fd0766
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Currently, if a user searches for an event based on a location name, the
location name is not displayed.
This commit shows the event location name when users search for the event.
Also add the "_getFieldsNames" method to easily override this method to
add a field name from another model.
task-2791031
Part-of: odoo/odoo#89796
This commit changes the event snippet tag option which was
misconfigured. Using the option fakem2m is indeed the way
to go to filter the events based on the given tags.
This commit also changes the way the domain works with tags:
tags from the same category will apply an OR condition
between them and tags from a different category will apply
an AND condition.
Task-3105126
closesodoo/odoo#109538
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Reduce the daterange widget width in the add
event website modal to avoid unecessary white
gaps.
Task-3081384
Part-of: odoo/odoo#106980
Adding a pricelist picker on the website event
front-end to allow the user to display the prices
depending on the selected pricelist.
Adding a picker to change the ticket pricelist
on the ticket registration page.
Task-3081384
Part-of: odoo/odoo#106980
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
before this commit,
Users are unable to fold/unfold tickets
after this commit,
Users can fold/unfold tickets
task- 3081378
closesodoo/odoo#106992
X-original-commit: ae5df3e46559185773d2826bfbd74335df4d122d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Fix the inline input fields which
width seems broken because of the new
always edit mode and the new form grid layout.
Specifications
==============
Limit the size of the confirmed attendees input
field in the event form and event type form to
display the confirmed attendees message in one line.
When using the debug mode, in the event templates,
inline the Register Button with its checkbox to avoid
line breaks.
Task-2996467
X-original-commit: 60bb067b1d3df699648967ab5b2e89aa164cee52
Part-of: odoo/odoo#106570
Steps to reproduce:
- create an event with a single ticket that has a description
Bug:
The default quantity on the website is set to 0 where it should be 1
Cause:
On this commit[1] adding description to a single ticket was done by
applying the multiple tickets layout but this also sets qty to 0
Fix:
removed the condition and added the description to the single ticket
opw-3018139
[1]:https://github.com/odoo/odoo/commit/9c4c953d004acaf916df348b670182b48b85d165closesodoo/odoo#105819
X-original-commit: e9ab599113125bd55fdfd2e3d95f71f52e001660
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: website_blog, website_crm_partner_assign, website_customer,
website_event, website_event_exhibitor, website_event_meet,
website_event_track, website_forum, website_hr_recruitment,
website_membership, website_sale, website_sale_loyalty,
website_sale_slides, website_slides, website_slides_forum
With commit [1], the "customize_show" options were moved in edit mode.
They were wrongly displayed for non-designer users. Trying to use those
would throw a warning at the user.
[1]: https://github.com/odoo/odoo/commit/17a8a37e9bfc5b787d9666597d43e63f0064919fclosesodoo/odoo#103142
X-original-commit: f2ca62a4a9ccb6713a39c100fc87c112619eac41
Related: odoo/enterprise#32768
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_event
The 'website_event.menu_edit_menu' menuitem was added on 'website_event'
module to the 'custom menus' registry so it can be displayed by the
'website_custom_menus' service if the event page has menus to edit.
The goal of this commit is to move this code to 'website' by using a
generic 'custom_menu_edit_menu' menuitem that will be cloned to edit
every content menu on the current page with the corresponding
'EditMenuDialog'. This is needed as a fix as it would be a regression
to not have this in 16.0 since it was possible to edit any menu on a
page in previous versions.
task-2973149
closesodoo/odoo#102997
X-original-commit: 6af5ad67c9657c7dcaf4afa1ecb4561e9c72270a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Avoid having multiple tooltips. We keep only one "t-field"
in the template. The other are replaced by a "t-out".
We also add a specific message when the datetime format is not
respected.
task-2942617
X-original-commit: a99d684507782cd0d9ff700dc7a12f7a46442403
Part-of: odoo/odoo#102545
*: website_blog, website_event
Commit [1] introduced new templates. This commit's goal is to build on
that template system to provide more flexibility for designers.
It adds new data-attributes to set on the first node of a template.
- data-row-per-slide: Allows for the template to tell a dynamic snippet
carousel how many rows of cards it should display.
- data-arrow-position: Allows for the template to tell a dynamic snippet
carousel where the arrows should be positioned.
(for now just bottom, or side)
- data-extra-classes: give the template the possibility to add extra
classes to the dynamic snippet instead of just the card.
This commit also removes options to select the amount of elements
displayed on each row. This is now only changeable through templates, or
by directly editing the snippet's DOM through debug tools. This was done
to reduce the amount of options visible, so that the user just chooses
a template and it is ready to go.
[1]: https://github.com/odoo/odoo/commit/49bd79b0bdca76415780bdfa199195371c2692e5
task-2677203
Part-of: odoo/odoo#80128
To reproduce:
Video: https://drive.google.com/file/d/1bAh7KA_5UhhIrr-qF5A5gOVWhk3_9clj/view
1. Have multi-language website
2. Event with one ticket
3. Reload page and click the "Register" button
-> in some cases there is a traceback
`/event/great-reno-ballon-race-2/registration/new: Function declared as capable of handling request of type 'json' but called with a request of type 'http'`
Reason of the issue:
As the button "Register" in the form is defined with `type="submit"` it will send the form as plain HTTP if clicked.
This behavior is modified in the JavaScript to prevent this default behavior.
However, if the button is clicked before the JS load, the HTTP behavior is used which does create the above traceback (as the `registration/new` route accept only `json` type).
Solution proposed:
Prevent the button default behavior and make it deactivated and let the JS activate it when it is ready
Note on stability:
As JS code and XML view is modified, this fix was thought so that the JS won't have an impact if the view isn't updated.
There is theoretically no way that the XML view would be updated without the JS being updated (except manual modification in the view or rollback on the version revision after performing a module update on odoo.sh). If it was the case then the button will be deactivated until the user change the number of ticket.
OPW-2946706
closesodoo/odoo#101311
X-original-commit: 5a8892497e2b0df5e1dc8085214687786954c878
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
*: website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
The website content list views should act as a page manager (click on
a record redirects to iframe, "CREATE" and "Publish / Unpublish"
buttons, ...).
The goal of this commit is to add a kanban version of these views for
key app models ('website.page', 'blog.post',...) since the same code
can now be used for list and kanban controllers / renderers since [1].
It is especially important in mobile where the kanban views are nicer
than list views by default.
[1]: https://github.com/odoo/odoo/commit/ed09db19c372da8d8be541f365117d1ce8e965ba
task-2889981
closesodoo/odoo#101174
Related: odoo/enterprise#31821
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: event, website_event, website_sale, website_sale_stock,
website_slides
With [1], new list views were created in the website app to display all
key models in the "Site" menu. Each view is based on the related model
base view in their related app, with some more website-related fields
(like the content URL, the SEO optimization, ...), etc. This commit
simplifies those views by removing some columns (make them optional) to
not make them feel bloated. Some changes were done in the base views.
- Products: simplify the website view by hiding 5 columns. Two were
stock related so it had to be done in a new view in
website_sale_stock.
- Events: simplify the website view by hiding 3 columns. Also move the
"stage" column at the end, in the base view too.
- Courses: simplify the view by hiding 1 column, this change is done
in the base view.
[1]: https://github.com/odoo/odoo/commit/da3f4c2aff92cca23ca2d7a87fa0eb5b1d7ce5feclosesodoo/odoo#99937
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- Now the start datetime and the location of an event is not editable
in the frontend editor.
It does not make really sense to change the location and for the
datetime it could lead to some Validation error as we don't know
in the card view the end datetime.
- Fix a display issue in the backend kanban view when the
location is too long and not inline with the icon.
- Align correctly the number of people in a community room
task-2845417
Part-of: odoo/odoo#91883
This commit removed static background color and the like in all event
modules. Since it's possible to configure colors from the website_editor,
we should used these ones in the frontend.
When an element is superposed on the background we used the later with a
mix of the primary color to have a demarcation and a better visibility
based on the colors chosen.
task-2845417
Part-of: odoo/odoo#91883
Since a recent commit[1] (that added invisible fields to avoid their removal
from the view when there's group applied on it and logged in user does not
fall under this group), the view definition were changed and so there were
few xpath broken which dependent on such fields.
- In event (event.view_event_form form view), invisible 'company_id' field
was added, which broke the the xpath in website_event since it was not
not robust and considered first invisible 'company_id' field, which now
should be the later one after commit[1].
- In mass_mailing_event_track, 'track_count' filed was added, that broke the
xpath in website_event_track_gantt.
This commit addresses both of the issues by:
- putting group name "right_event_details" in the "event.event.form"
form view and providing an xpath with group name in the
"event.event.view.form.inherit.website" form view to adapt the changes.
- removing the 'track_count' invisible field from 'mass_mailing_event_track'
module because that field in the original view does not have any group
applied at view or model level so we don't need to add the same one as
invisible field in the view
This commit also remove the invisible 'seats_expected' field from event
form view in 'mass_mailing_event' module for same reason as 'track_count'
field; it does not has any groups applied at view or model level so we
don't need to add the same one as invisible field once again.
commit[1] - https://github.com/odoo/odoo/commit/0501bbd62e517f6c215d9e7e36d61747c7f5816b
task-2964291
closesodoo/odoo#99212
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
As indicated by previous commits, new custom list views are created to
fill the "Content" area of the main website menu with key app models:
blog posts, events, forum posts, jobs, products and courses (+ some in
the enterprise version, see related commit).
Those list views will act as the page manager one: a click on an item
redirect to the website iframe, the create button acts as creating a
record via the "+ New" systray button while being on the iframe, the
delete button will in the future allow to know the page that mentions
the related object before deleting it, etc etc.
task-2889981
closesodoo/odoo#98937
Related: odoo/enterprise#30782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event, website_sale
The "Site" menu will now be organized in 3 sub-areas, the last two being
named "Content" and "This page". The first area contains a link to the
website iframe and the menu editor. The "Content" area will contain
menus to list all contents of the website (page, products, events, ...).
This commit only moves the "page" one, the others will be created by
other commits of this PR. The "This page" area contains elements
specific to the page (html editor, page properties, ...).
task-2889981
Part-of: odoo/odoo#98937
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Improve UI of event app.
Detailed changes:
1) change the wording of the selection item "sponsor" of
event_sponsor.exhibitor_type from "sponsor" to "Footer Logo Only"
2) event name placeholder changed to (quote added):
e.g. "Conference for Architects"
3) in the track page and exhibitor page, if the description is empty:
- for external user: hide the empty description zone for external user
- for internal user: display an alert (info) inviting the user to complete it
with a link that triggers the edit mode.
3 bis) in the track page and exhibitor page, the page and the menu aside
are glued to the top. Add some space there.
4) display unpublished tag on the side menu for unpublished tracks
Some other changes:
- When some content are empty, there were some awkward horizontal lines
separating nothing, we have decided to remove them
- Fix track layout and improve mobile layout
Task-2692907
closesodoo/odoo#83488
Related: odoo/enterprise#23798
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
As a stable fix, to not touch XML templates and break existing
translations, the ⌙ character was automatically replaced by └ which
makes more sense for the usecase and should work properly in all
browsers. The ⌙ character is actually rendered mirrored on Windows 11
Chrome (and others) as the font used for those unicode characters is
left to the browser. We could force a font of our own but it's probably
not worth it.
A better solution with a SVG or CSS solution has to be done in master.
That would unify the look of the symbol across all browsers and
also prevent special characters to be placed in translations.
With this forward-port commit, we'll start first by using └ via a CSS
rule. Three new classes have been created: o_we_sublevel_1,
o_we_sublevel_2 and o_we_sublevel_3. Adding any of them on a widget
automatically adds the └ character. Then choosing 1, 2 or 3 controls
the indentation, which was previously controlled by placing the  
HTML entity directly inside strings.
This commit also takes the opportunity to fix some of those level
indentations (sometimes 2 was used instead of 1 or 1 was used instead of
2, etc) and also review some related labels.
closesodoo/odoo#97361
X-original-commit: e5d45643598671077ade7e41f0dbfe2b502665b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
This commit adds a new menu item in the "Site" menu section.
This "Edit Event Menu" item is only shown when a [data-content_menu_id]
element is displayed within the iframe (such data attribute is added on
the event menus).
The contentMenuId is taken from the currentWebsite.metadata to keep data
taken from the iframe's document centralized in the service.
The spec is different from the previous implementation, that was
prompting a dialog to select the menu to edit, before prompting the
dialog to edit the menu. Here we have two different dropwdown items.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_links,
website_livechat, website_slides, survey, web_editor
This commit removes the website navbar root widget, as the edition is
now handled in the backend through the client action and custom menus.
It removes associated widgets and their css.
See merge commit for more information.
task-2687506
*: website_event_meet
This commit adapts "customize show" options from website event modules
by creating new options available in edit mode. These "customize show"
options used custo JS code which was adapted to work with the global
options system.
See merge commit for more information.
task-2710582
*: website_event_exhibitor, website_event_track
This commit adapts "customize show" options from website event modules
by creating new options available in edit mode.
See merge commit for more information.
task-2710582
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides,
website_slides_forum
The goal of this commit is to add dialogs to create new website content
using a 'target:new' action on the form view and an overridable
"website" form controller.
See merge commit for more information.
task-2687506
*: website_event, website_forum, website_slides
As the first commit of the merge of this work at [1], this moves files
without modifying them to preserve code history and ease forward-ports.
This part is about moving static XML to non-static files where the
XML will be changed into view definitions (as some UI now become normal
backend views). This cannot be a standalone working move of course.
So it was not done in the first commit but here, just before the
relevant commits of the merge.
[1]: https://github.com/odoo/odoo/pull/89223
See merge commit for more information.
task-2687506
* 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>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
Purpose
=======
Avoid having "dead-ends" when registering to an event.
Specifications
=============
Add link to event to registration confirmation for free events.
Display list of each bought event on the confirmation page for paid
events.
PR: odoo/odoo/pull/78599
Task-2657635
closesodoo/odoo#78599
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With stored computed seat attributes, the database can be flooded with update
queries for the stored values for the event (ticket) seats computations (such
as reserved, expected, and available seats).
This can especially occur when a communication is sent to many people about
an event with a registration link, many users may want to register at the same
time, possibly resulting in concurrent_update errors.
In this commit, we remove the `store=True` attribute of those fields, and
therefore remove the Reporting/Event feature depending on them and rewrite some
domain searches and _compute fields in the event and event_sale modules.
This also impacts the way constraints are enforced on the number of
registrations vs defined maximum as no stored value is directly available.
For performance reasons, all events and tickets are now shown on backend form
views, with seat availability added in their displayed name.
Misc
To avoid delaying the inevitable, the Event configurator modal/wizard now
validates event/ticket consistency at closing.
The UI of the RegistrationEditor wizard is also improved:
* A warning alert will tell users that free registrations were not confirmed
because of insufficient seat availability.
* A first step to better explain the consequences of the actions taken on the
modal was to be taken, here via the description and buttons wording.
Tests
Query counts are (indeed reduced) and updated. However, as local testing with
`test-tags=/test_event_full` ("tef_only") is currently not reliable, these
values were updated by applying the same change from the commit as the one seen
for the runbots, while a "?" is appended to show this uncertainty.
Task-2654816
See odoo/upgrade#3118
Part-of: odoo/odoo#81583
This commit add the way to specify the Plausible shared key auth token and
the plausible domain on your website to have the Plausible Dashboard integrated
in your Website > Dashboard > Analytics menu.
Some custom event are already pre-configured as:
Push an event 'Shop' on confirmation on ecommerce (with amount bucket +/- 50)
Push an event 'Lead Generation' on:
'Thank you' page of contactus
Confirmation of subscription for an event
From this way, the end user can just add a goal 'Lead Generation'
or 'Shop' on Plausible to have the Goal values visible.
closesodoo/odoo#91058
Related: odoo/documentation#2007
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
PURPOSE:
When a website_event with a submenu is created, some default pages
contain an empty space to lower the footer (see odoo/odoo#89602).
On these pages, the sponsor icons are now at the bottom of the page,
on top of the footer, instead of just below the page title.
Task-2850546
closesodoo/odoo#91045
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In 2 ways:
- by ignoring prefetched pages: indeed some page were reported inaccurately
as being viewed by the user when they were only prefetched.
- by adding the page /event in the tracked page as the page is obviously
important in the event business
Technical notes:
- The prefetched pages are ignored thanks to an header X-Disable-Tracking added
on each prefetch request in the service worker.
- Adding the page /event as a tracked page has increased the number of queries
when browsing the page /event. That's why some query count have been updated in
TestOnlineEventPerformance.
Task-2476513
Part-of: odoo/odoo#86031
Xavier Luyckx (xlu)