- 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
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: 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
* = test_website, website_blog, website_event, website_forum, website_sale,
website_slides
`_search_get_details` extension in other modules can now be performed with
fewer lines of code by updating a search type-to-model mapping, without the
need for method override.
This will also have the benefit of slightly reducing the call stack length,
avoiding some unnecessary `if` statements and list lookups at runtime.
Task-2957361
closesodoo/odoo#98423
Related: odoo/enterprise#30946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* website_event, website_slides
Note that `restricted_editor` is the new technical name used instead of
`publisher`
Before this commit, the `is_restricted_editor()` method was actually
checking for `designer` rights and not `restricted editor` ones.
Indeed, a restricted editor (previously publisher) never had the write
right on ir.ui.view.
Despite the method name being wrong, it was still correctly used where
we actually checked for designer rights and not publisher/restricted
editor ones.
Also, the method was checking for write access on ir.ui.view instead of
checking directly if the user had the related group.
While it wasn't really wrong, it was also including people who would
have the write right on ir.ui.view but were not part of the designer
group.
This doesn't really makes sens, as we don't want someone which received
that write right on ir.ui.view from another module (not related to the
website) to be considered as a website admin -> we don't want to show
them website admin UI and stuff like that.
The method could have simply be renamed to `is_designer()` and could
have just checked for `has_group(designer)`, but having such an helper
seems overkill, we would end up with as many utils as there is groups.
At the end, this PR:
- removes the confusing util method
- replace it by has_group checks
Part-of: odoo/odoo#98200
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
Steps to reproduce:
- Install `website_event` module
- Go to Events and edit `Design Fair Los Angeles` event
- Edit the title and make it very long then save
- Go to the Website then click on Events in the menu
- Click on Customize and disable `Layout - Columns` to have
a list view.
Issue:
The cover is hidden on edited event.
Cause:
It's a know issue:
https://stackoverflow.com/questions/36247140/why-dont-flex-items-shrink-past-content-size
Solution:
Set min-width: 0 to the div arround the title if screen size bigger
then `sm`.
opw-2882533
closesodoo/odoo#99078
X-original-commit: f9068079bd3535146727f710bc7a3aca863524ab
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
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>
When a record is created through xml data, its HTML fields should
receive a `type="html"` attribute, not a `type="xml"` attribute.
When important XML data with XML type instead of HTML type will have 2
differences:
- The field value will be prefixed by `<?xml version="1.0"/>`
- If the HTML contains multiple root nodes, the value will be wrapped in
a `<data/>` tag.
See `_fix_multiple_roots()` and the `xml_import` class for more details.
closesodoo/odoo#98239
Related: odoo/enterprise#30491
Signed-off-by: Xavier Morel (xmo) <xmo@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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
- 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
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
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, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
*: web, web_editor, web_unsplash, website_blog, website_event,
website_forum, website_hr_recruitment, website_links,
website_livechat, website_sale, website_slides, website_twitter
This commit fixes two issues related to the loading the wysiwyg and
editor assets.
The media dialog components are now defined in a new assets_media_dialog
bundle, to make them available both in the frontend (needed to post
comments on the forum for example), and in the backend (used in the
context of the wysiwyg edition or in the seo dialog). Ideally, The media
dialog component would lazy load its own bundle, but right now, it is
not possible when used in a ComponentWrapper.
The wysiwyg assets are now completely loaded in the frontend, after
creating the website root, when the frontend is displayed in an iframe.
It would be better if the frontend loads only what it needs of the
wysiwyg assets (some editor classes and the drop zones css), an
improvement would be to create an assets_wysiwyg_frontend or
assets_wysiwyg_minimal bundle.
The website edition components are moved to the assets_editor bundle.
For now, this bundle is included in the backend and the edition menus
are hidden from the users that are not website publishers. Ideally, the
client action would lazy load the assets_editor, only if the user is a
website publisher.
Many optimizations regarding assets will be done post-merge.
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
*: mass_mailing, web, web_editor, website_blog, website_event,
website_event_meet, website_livechat, website_sale, website_twitter,
base
This commit does 3 things:
- Adapt existing code so that the editor can be run outside of its
editing element. Prior to this commit, it was expected that the
editor would be attached to the element it was currently editing.
This needs to change however as the editable is now inside an
iframe for the website edition. mass_mailing already had a similar
approach but the editor was started within the iframe.
With these changes, the editor is alongside the iframe, editing
the content that's inside it. This allows multiple features
such as reloading the iframe while keeping the editor visible and
resizing the iframe for a mobile preview.
- Adds logic to the wysiwyg_adapter so that it can undertake
the duty of the previous widget sytem. The wysiwyg existed not only
in the legacy widget system, but most importantly in the frontend.
One of the duties of this adapter is to send events inside the
iframe when it is necessary to reach the frontend public widget
(i.e. widgets_start_request)
- Removes existing SCSS that is no longer used.
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
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_livechat, website_sale, website_slides
The NewContentModal component is added. It displays tiles, which will
install a module if not already installed, or perform an action defined
by the module otherwise. So that modules can patch that component to
define an action when installed (for example, website_sale will handle
the logic of creating a new product), the elements to displayed and
their state (NOT_INSTALLED, INSTALLING, INSTALLED) are listed in the
state of the component.
A key 'isDisplayed' is added on the new content elements that should not
be displayed to the user, depended on his security groups.
By default, the new content elements are displayed to the system user.
See merge commit for more information.
task-2687506
*: web_editor, web_unsplash, website_event, website_blog,
website_event_meet, website_forum, website_links, website_livechat,
website_sale_slides, website_slides
With [1], many files will move as the website UI is moved in the
backend. This commit moves all the static files (JS/CSS/XML) to their
final destination without modifying them, in an attempt to preserve
some history and ease some forward-ports.
After this commit, everything works as before as the files are simply
renamed and the references to them adapted.
However, technically, many files will actually be split into multiple
files by the work made with [1]. While it is theoretically possible to
preserve history over multiples files, this would require inner merge
commits, which does not go well with robodoo. In those cases, the "main"
file of the split was chosen. Mainly, 4 worth-noticing splits were
detected (and so the history moved only to the first file):
move: addons/web_editor/static/src/js/wysiwyg/widgets/media.js
to: addons/web_editor/static/src/components/media_dialog/file_selector.js
- addons/web_editor/static/src/components/media_dialog/search_media.js
- addons/web_editor/static/src/components/media_dialog/image_selector.js
- addons/web_editor/static/src/components/media_dialog/document_selector.js
- addons/web_editor/static/src/components/media_dialog/icon_selector.js
- addons/web_editor/static/src/components/media_dialog/video_selector.js
move: addons/web_editor/static/src/js/wysiwyg/widgets/upload_progress_toast.js
to: addons/web_editor/static/src/components/upload_progress_toast/upload_progress_toast.js
- addons/web_editor/static/src/components/upload_progress_toast/upload_service.js
move: addons/website/static/src/js/menu/content.js
to: addons/website/static/src/components/dialog/edit_menu.js
- addons/website/static/src/components/dialog/page_properties.js
- addons/website/static/src/components/wysiwyg_adapter/page_options.js
- addons/website/static/src/js/website_page_list.js
move: addons/website/static/src/js/menu/edit.js
to: addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js
- addons/website/static/src/systray_items/edit_website.js
- addons/website/static/src/components/editor/editor.js
Notice that as those moves were made post-work and the rest of the work
(80+ commits) rebased on top of it, some commits may remove more than
they should in a moved file to then reimplement some of what was
removed in a later commit... ideally this should have been avoided of
course but keep in mind that the final files are just entirely rewritten
and split as converted to OWL. It seemed however worth it to keep most
of the inner history of the work made here to see step by step what was
done. [1] will obviously be merged with a merge commit, binding the
whole work together.
[1]: https://github.com/odoo/odoo/pull/89223
task-2687506
*: website_blog, website_event, website_sale
The "website.snippet.filter" model introduced at [1] was not marked to
have its "name" field to be translated. As those names are shown in the
website editor panel to be able to select a filter, they have to be
translated.
[1]: https://github.com/odoo/odoo/commit/0e7640b5f22d2bea04bbe22d3189cff7e03af545
opw-2852416
closesodoo/odoo#93074
X-original-commit: fc9e5619331cf22f8605a72907153f9431ca6b15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
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>
PURPOSE:
This commit adds a min-height property to event pages so that
the footer does not take the entirety of the screen when a page
has little content.
To not have a strange empty space on the booth event page when no booth
is set or when the event is finished, the related error messages are
now displayed below the cover instead of inside it.
It also removes the default grey background on some templates,
so that the theme background color is used instead.
Task-2831951
closesodoo/odoo#89602
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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
Jérémy Hennecart (jeh)