Purpose
=======
Registration Desk promenade.
Bunch of QOL improvements to make the handling
of events easier.
Specification
=============
- Modify the attendee search template to have the search
in this order:
* Participant (search in name, email and company)
* Company
* Booked by
* Selected Answers
* Ticket
* Event (Just for the multi-event mode)
- Make attendee registration status bar clickable to ease
the state modification.
- Attendee registration kanban view improvements:
* Display the company.
* Add a ticket icon in front of the ticket type.
* Display the answers selected while registering (only
for the questions of type selection) as tags.
* Always use the fa-check icon for the card buttons
(secondary for confirmed, primary for attended).
* Add a button to go backwards (confirmed to unconfirmed,
attended to confirmed) to ease the state modification
from the kanban view. As we now have 2 buttons, widden
their allocated space to make the clicks easier.
Task-3469490
closesodoo/odoo#134479
X-original-commit: c95db124cac8031e928f8fcdc5d47ebbc7f7f341
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Amélie Dieudonné (amdi) <amdi@odoo.com>
- Add the registration answers of the attendee in the registration
summary.
- Add a mobile kanban view for answers on the attendee form to
make them more visible.
task-3491881
closesodoo/odoo#134404
X-original-commit: 35ed7ccfd24ea31df86f9c863e75f1cb0fb77f0d
Related: odoo/enterprise#46957
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
To reproduce
============
- create event with ticket that can be sold on website
- make company field empty in event form
- buy ticket from website and go back to the event form > Error raised
Problem
========
- the method `_compute_sale_price_subtotal` is using `company_id`, but as
it's not required in Form View we give it a null value
Solution
========
- make `company_id` required from view
- if `company_id` is not set, use the current company from `env`
- Define constraint on `website_id` as the user should choose website from
same company of the event
opw-3395108
closesodoo/odoo#132173
X-original-commit: 0d70e38ab4bab850ee4bddc7b21b4c6c10809294
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
When having a multiple website filters appear on both website.
event_tag_category determines what the filter should be. The problem is if I assign one event_tag_category
one website it also appears as filter on other website.
task-3254058
closesodoo/odoo#118136
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
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
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
Currently, website users/visitors are not able to search the events based on
where they happen.
This commit improves the behavior by allowing the users/visitors to type the
city/country name in the search box and returns the events that are happening
in the country or city that matches the search term. To allow this, we have
utilized the search_extra search option and searching the matching events
with sudo because public users can not access the address_search m2o of the
event. Apart from that, this commit also adds the ability to address_search
the event based on location (name) of the address on address_search.
Note that searching with sudo is just to add event ids in the domain. The final
result will be returned with non sudoed environment and so the record rules are
always respected.
TaskId-2791031
Part-of: odoo/odoo#89796
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
*: test_website, website, website_blog, website_event, website_forum,
website_sale, website_slides
Reverts this refactoring because it breaks multi-tenancy: if several
databases run on the same server and different modules are installed
in each database, the global variable becomes wrongly populated.
Steps to reproduce:
On runbot:
- Go to the `-base` URL or simply select the `base` DB
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model
On Odoo.com saas DB:
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model (unless you installed
each and every module related to the search snippet)
Locally:
- odoo-bin -d first -i website --stop-after-init
- odoo-bin -d second -i website_blog --stop-after-init
- odoo-bin -d first,second
- Try to use a search bar on "first" database (using "Search in
Everything") => it tries to access the blog models.
Revert of PR: #98423
opw-3045092
closesodoo/odoo#105077
X-original-commit: 5806f71af1b6f44aac063f7e504be736300f699d
Related: odoo/enterprise#33669
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
* = 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>
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>
* 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>
* = website
Change the wording of the sms reminder template to make it sound friendlier and
more complete. The sms will include the event address if it is defined.
Otherwise, it will link to the event page if website is installed.
A one line-formatted version of the venue is added to the model to be used in
the template and other places.
This required to update `event_registration.get_date_range_str` to not include
the time when describing an event happening more than a month from the current
date, which makes sense as there is no reason to specify the time only in that
case, and we add the time somewhere else when it's useful anyway.
For consistency, Wembley Stadium is updated to London timezone in the demo
data.
Task-2777183
closesodoo/odoo#85664
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanup all the places where an hour or a datetime is been used
to display with the date the corresponding timezone.
The goal is to know the timezone used where a datetime is displayed
on the event pages.
task-2458013
COM PR: odoo#78049
Part-of: odoo/odoo#78049
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@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
The concept of 'parent_id' on website.visitors was introduced in the saas-13.3
stable while implementing the "event online" feature:
However, it should have been part of the website module from the start since
it's a 'global' concept that does not depend on events at all.
See #53540 for more details.
This commit aims to clean the code by moving the field to the website module,
which allows a nice cleaning of associated overridden methods as well.
Along with that, we move the website.visitor demo data from the event module to
the website module, allowing a fresh install of website to showcase some of our
visitors feature.
We also took this opportunity to do some minor improvements in the visitors
kanban view in order to make relevant information more visible.
Task-2429652
Part-of: odoo/odoo#65113
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
website{_*}: website, website_blog, website_event, website_forum,
website_sale, website_slides
Since the generic search bar was introduced in [1] all text fields were
truncated in search results.
This caused problems for long URLs which were truncated as well, and
therefore could become invalid.
After this commit URL fields specify `'truncate': False` in their search
detail metadata, which informs the rendering to skip the text truncation
step for that field.
Also added previously missing controller-level tests of the
autocompletion.
Steps to reproduce:
- start odoo with website_forum and demo data
- go to the Help forum
- search for "configure" in the Help forum
- click on the auto-complete suggestion
- => redirected to a 404 page because the URL was shortened
To test the fix on other models, use a long enough name that causes the
problem. E.g.: "This product has such a long name its URL would have
been truncated without the fix contained in this branch".
Note that the problem did not occur on blogs because the URL does not
contain the name, but the same fix was applied for consistency.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2727788
closesodoo/odoo#82621
X-original-commit: 045f741be35e62f5e3a636490c6c1d475b5d78eb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
With this commit we ensure website_menu field is computed before calling
create. Indeed otherwise it is computed after the create if value is not
given and stays to False. This is due to the compute that does not distinguish
a False value from user from a False value added as default. This breaks
the event type -> event synchronization when no form view is used (either
through UI or in code).
With this commit, it is computed before resuming the creation and field
is correctly synchronized with the template value unless the user gives
a value at create time.
Task-2341656 (Event submenus shenanigans)
Part-of: odoo/odoo#81068
Currently if event website menu main checkbox is unchecked the related website
menu is removed. Its children are also removed through the cascade attribute on
parent_id field.
However this is done in SQL, meaning some overrides on unlink of website.menu
is not called. This does not properly cascade unlink views linked to website
menus through the specific "website.event.menu" model. This leads to some
views staying alive in DB. This causes issues with web editor when calling
``_views_get`` as he may receive several views linked to a given view_id (key)
while it expects only one.
We fix that behavior by removing the menu and its children explicitly. This
calls various overrides done in website_event.
Task-2616588
X-original-commit: 9722baee83adea9808de1247c300e226cf6fc537
Part-of: odoo/odoo#80391
PURPOSE
Replace the old event snippet which was a simple template with a
javascript file doing a rpc by a new one directly inherited by the
dynamic snippet.
The old snippet was displaying a list of the upcoming events based
on the user's localization. With this commit, it will be completely
replaced by the new snippet. The migration will convert the old
snippets to avoid versioning and keeping ugly code.
The new snippet allows the user to set multiples tags to display
only the wanted events on the website.
LINKS
Task-2489680
PR : odoo/odoo#68644
Related: odoo/upgrade#2406
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We don't have any option to see to see all the events currently. However
this option can be useful sometimes. For example you are looking for an
event but don't know whether it's already finished or upcoming. Or if you
are looking if some event "types" are available (e.g.: Do they sometimes
organize Tennis competitions ?).
In this commit a new filter is added in the last 'All events' which allows
users to see all the events.
Task-2581308
Part-of: odoo/odoo#75066
Before this commit the `_search_get_detail` result contained callback
functions to handle special behavior during fetching and rendering.
After this commit a `website.searchable.mixin` is introduced that must
be inherited by models that participate in website-based searches.
Custom behavior previously achieved with callbacks is now achieved by
overloading methods of this mixin.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
(*: website_blog, website_event, website_forum, website_sale,
website_slides)
Before this commit the search bar was specific to products.
After this commit a generic search bar is available as a general feature
of website which can be configured to inspect specific models.
The snippet is used to replace the old search bar in blog, courses,
event, forum, page and shop.
The search results of these pages and the autocomplete of the search bar
run through the same search mechanism.
A new hybrid results page has also been created as a target of a search
on "Everything".
In each involved module, `website._search_get_details()` is implemented
to return search metadata for every model related to the `search_type`
parameter.
Search metadata for a single model is returned by `_search_get_detail()`
on that specific model.
The autocomplete runs through the additional
`website._search_render_results()` pre-rendering step that prepares the
data to fit in the autocomplete template.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
The purpose of this commit is to change the default values of an event cover
image to improve the UX, especially while using the editor.
Task-2488019
PR odoo/odoo#68901
PURPOSE
The event foldable badge is currently not very user-friendly in terms of usage
and style.
This commit aims to re-work it visually as well as getting rid of multiple
technical flows (unnecessary fields / no studio anchors / ...).
SPECS
Preliminary cleaning : Unify both foldable badge templates into one.
The "event badges" report can be printed from 2 different sources, from the
event.event itself as a preview and from the event.registration as an actual
badge for a specific attendee.
The implementation was done using two different templates, leading to a lot of
duplicated code and potential issues when editing one template that would not
modify the other accordingly.
This commit unifies both templates into one.
When the report is printed from the event as a "preview", we simply check that
the attendee variable is missing and print placeholders instead.
Main changes : Rework the whole foldable badge template
1. Get rid of unnecessary fields
The foldable badge template used several fields on the event.event model itself
that would allow customizing the report per event.
However, there were actually no way for the user to access and edit those
fields, as they are not part of any views.
We therefore removed them (badge_front, badge_back, badge_innerleft,
badge_innerright, event_logo).
And instead offer a single new field (ticket_extra_instructions), available on
the form view of the event, that allows to easily customize the foldable badge
and adding instructions specific to this event (how to come / what to bring /
...).
2. Visual changes
The report was re-worked to make it look a bit more recent, as the previous
look was very basic and was not very attractive.
This was done using a specific scss file that allows defining rules without
bloating the template with long style attributes.
In addition, we added some pictures that help the attendee understanding how to
correctly fold the printed A4 sheet into a badge and slide it into the holder.
All the information that were previously on the report should still be there.
3. Relocate action from website_event to event
As a bonus, we moved the reporting action from website_event to event, in order
to have everything that is related to this foldable badge in the same module.
Side note: scss disclaimer
As the reporting engine does not allow complex class/rules building, we had to
implement this nice layout using very well placed background-image and
"pixel perfect" sized elements.
You will see a lot of hardcoded numbers, mainly on heights, but it can't be
helped.
LINKS
ENT PR odoo/enterprise#19349
UPG PR odoo/upgrade#2599
Task-26779
Now that all menus are managed the same way using a menu type and
clear definitions we can set all menu type definitions to override
_get_website_menu_entries. This is just some code cleaning and
has no functional impact.
Task-2577079
PR odoo#72411
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
If user selects 'schedule appointments' as main objective in the configurator
and if the website_calendar module is installed then the Call To Action of
snippets s_banner, s_cover and s_call_to_action is changed to 'Schedule an
appointment' and redirect user to '/calendar' on click.
task-2518565
closesodoo/odoo#71162
Related: odoo/enterprise#18690
Related: odoo/design-themes#5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
BEFORE THIS COMMIT
The option adding an extra register button in top right
(at submenu height) of an event website page was presented as a
checkbox 'Register Button' on event form and 'Add Register Button'
on event type form.This was easily mistaken as the option of
allowing / preventing user registrations, which is not the case at all.
AFTER THIS COMMIT
In both event.event and event.type, this option is renamed
'Extra Register Button' to clarify its purpose and prevent such
a confusion.
--- Links ---
Task Id - 2578891
COM PR - odoo/odoo#72686
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Clean the ACLs related to the Event application.
Add a new group to manage the registration in the entrance of an event. This
group should not be able to modify or remove records in Event but should be
able to create and manage the registrations.
Specifications
==============
Now, there are 3 event groups
* ``Registration Desk User``, who can manage the registrations and
read all event-related information;
* ``Event User`` who can create event, sponsor, ticket... His role is
to globally handle events on a day-to-day basis;
* ``Event Administrator`` who can create event type, sponsor type,
ticket type... His role is to manage the way events are managed withint
its company:
Each group implies all previous groups.
Compared to previous event users gain a lot of rules, allowing to update
records like tickets, registrations, ... Low-end event users should now
use the registration desk group.
Links
=====
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
Problem
-------
Since
https://github.com/odoo/odoo/commit/d3b18979bfb5496fa4370fdf03a806c469127730,
when a visitor register for an event, the fields in the POST are checked against a list of allowed fields.
The list is hardcoded inside the method _process_attendees_form.
Solution
--------
Move this list in a specific method that can be easily overidden by
another module
closesodoo/odoo#67080
X-original-commit: ebadf16c7c38ca52ec4c5ce871c2584aaa98b91d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Thibault Francois <tfr-odoo@users.noreply.github.com>
Before this commit, a participating badge was displayed on the event even if
the user's registration has been canceled. This is a strange behavior.
After this commit, the participating badge will be hidden if all the user's
registration have been canceled.
Task ID-2432546
closesodoo/odoo#65702
X-original-commit: 125e5401123d8e4bc7656ac7534cc9290451adbc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In backend, we may want to use tags for advanced use cases like reporting,
filtering, aggregating in spreadsheet, ... However right now we cannot
define tag categories dedicated for 'internal use only'.
Similar to eLearning, this commit introduces facility to decide whether or
not to show the tag categories on the website. It is based on website.published
mixin. is_published field will be used for taht purpose. ACLs are updated
accordingly. If the category is hidden from the website then it is used for
internal purpose only.
In order to make all the events menu together, this commit moves the
'Event Tags Categories' menu after 'Event Stages'.
COM PR odoo/odoo#63485
UPG PR odoo/upgrade#2088
Task Id-2300230
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Community menu field is added in website_event module. It is used in two
inheriting modules, website_event_meet and website_event_track_quiz. There
is no other common ancestor for those two modules.
In website_event, community menu field should be False and not displayed
as it has no real use. Only in those sub-applications it should be
computed like other menu fields, and displayed in event views (both
event and event type for configuration).
PR #56340
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@981f95b and odoo/enterprise@1472202
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
Allow to configure Menu CTA button on event from event_type, like other
frontend related menus and buttons.
Add settings to ease discovering and installing sub event features like
* meet;
* exhibitor;
* live mode;
* quizzes;
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 online to website event.
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
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
Quickly reorganize some bits of code in website_event module to ease future
integration of code from _online sub-modules. It also helps understanding
and finding its way through the module.
Split python files by model: notably event.type outside of event.event file
and code.
Reorganize templates by main use
* _list: list view of events;
* _page: page view of events, either event itself or registration flow
(_page_registration);
* move side templates in side files;
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
amdi-odoo