The event registration form is made up of a public widget that
instantiates an internal normal widget. All public widget are
automatically destroyed when entering in edit mode as well as the widget
it created. Therefore, it's main element is removed from the DOM when
the widget is destroyed. Here, we're detaching the main element from the
internal widget before the widget is destroyed so that we avoid to
destroy his main element from the DOM when entering in edit mode.
task-2210733
closesodoo/odoo#52426
X-original-commit: d515e4233a009250f41e8a1c1b02235685a69532
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web, web_editor, website_blog, website_event
New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets:
they come with a background color, a text color, headings colors, a
link color, primary button colors and secondary button colors which
will later be possible to customize by the user.
The classes are made so that they are working on two levels. So if a
column receives a color class and the snippet too, everything will work
fine. More than 2 levels are not supported and the editor is made so
those cases should not appear. See o_colored_level class.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
PURPOSE
Before this commit to activate the sub-menu, the tracks and the track proposal
you had to do it on the event form view. After this commit you'll have to go
on the event website page to change those options (through the customize dropdown)
SPECIFICATION
Remove the 'website_menu' / 'website_track' / 'website_track_proposal' from the
event form view and create a toggle option in the customize dropdown on the event
website page instead.
LINKS
Task ID : 2198660
PR : #46659
Purpose:
Improve the registration on front-end by allowing the manager
to customize it and display more informations to users about the tickets
and the status of the event.
Specs:
For event manager:
Allow users to decide wether or not they want to unfold/fold
ticket details on their event. The reason behind this is that
some events might have 5+ different tickets and having them unfolded
would bloat the UI quite horribly.
By default, ticket details should be unfolded with no possibility for the end users
to fold it back.
Always display a button for the manager to go configure the event in back-end
For users in general:
Show price range in case the ticket details are folded.
Clearly show the user that a particular ticket is sold out/expired
Cleary show the user that registrations are open/closed/sold out
LINKS:
TaskID:2162438
PR: #43856
This commit changes the display name for the model event.type from
"Event Category" to "Event Template"
This change was needed before introducing the new model event.tag.category
which will be used to group tags (event.tag)
This commit introduces two new models: event.tag.category & event.tag
The tags will be grouped by category and will be used to filter events.
In the front-end, if the user activates the "filter by categories", each
event.tag.category will generate a new dropdown of related tags.
Clicking on one of these tags will add a new "tag badge" above the events
(same way as in eLearning).
LINKS:
TaskID:2162438
PR: #43856
PURPOSE
Create a tour for Events to introduce new users to this freshly
revamped application.
SPECIFICATIONS
In 'website_event' module the tour steps extends the 'event' tour steps
LINKS
Task ID : 2180175
PR : #45612
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit moves some step utils in a dedicated file and add new ones.
These steps will be very useful for the Main Flow Tour to avoid
duplicated code.
To do this, we also had to transform it into functions to allow
utils to call each other. Existing one are converted for
standardization purpose.
Note that 'WEBSITE_NEW_PAGE' wasn't considered as an util.
This is a very simple step only used twice.
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
In this commit we move frontend part of ticket support from website_event_sale
to website_event. Now eCommerce / event integration adds only payment
information when registering.
About tickets
* if there is no ticket -> generic registration allowed;
* if there is one ticket -> quick registration box;
* more than one ticket -> unfolding registration box with all available
tickets;
About price
* sale not installed -> no mention of price. A ticket without price is not
free. Its description allow to tell how to pay for example;
* a price is set: price is displayed;
* no price is set: FREE is displayed;
Most event frontend templates and controllers are therefore moved from
website_event_sale to website_event. Only part about pricing and sale order
creation is now located in website_event_sale.
Buy flow remains mainly untouched. Indeed this commit is mainly about moving
template to support tickets.
LINKS
Task ID 2177281
Community PR #43488
* website_event
Commit https://github.com/odoo/odoo/commit/a153ed42a09f8b7f5e0865112eb7d5affc22a353
solved a big problem which was that when an undo/redo is performed, the
whole DOM was reconstructed breaking all the JS relying on the old one.
For example, the latest blog posts which are dynamically loaded in JS
were not removed before saving since the JS relied on the old DOM... and
this broke the page because that dynamic content contained non-valid
XML markup. The solution was to destroy all JS widgets before applying
an undo/redo and rebuilding them all afterwards. Ideally this operation
should be done on the undo recording action but this would have a huge
flickering impact since many DOM would be destroyed each time the user
types text (flickering which is also bad on undo/redo but it is more
acceptable).
The problem now is the following: if a widget, like many, is declared
like this:
```
start: function () {
this.$el.append(/* Some dynamic content on page loading */);
},
destroy: function () {
this.$el.find(/* Dynamic content to remove */).remove();
},
```
Then it works in all standard cases: dynamic content is loaded on page
load and is removed when saving the editor. But this happens with the
undo/redo system:
1. The users types text, we record an undo, which is the whole page
current DOM, containing all the dynamic contents.
2. The users hits CTRL-Z:
a. We destroy all JS widgets, calling destroy, the dynamic content
is removed from the page.
b. We replace the whole DOM with the one that was saved. That one
contains the dynamic content DOM.
c. The JS widgets are recreated, calling start... creating the
dynamic content again.
Result: the dynamic content appears duplicated. On save, depending on
how the destroy was implemented only the last generated content may be
removed or both... but in any case it appears duplicated during edition.
Hopefully, our current stable version do not contain that many dynamic
content so a perfect amelioration of all of this can be found in master.
As a fix, this commit introduces an extra step between (a) and (b):
we remove the dynamic content of the DOM-to-re-apply before applying it.
For this to work, widgets have to mark their dynamic content with the
class 'o_temp_auto_element' when creating it. They also must add the
content they replace on the 'data-temp-auto-element-original-content'
attribute.
closesodoo/odoo#44025
X-original-commit: f0d2559afd3094f6fbd7e6788f7c10fa421c9080
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website_blog, website_event, website_form, website_mail_channel,
website_mass_mailing, website_sale, website_twitter
+ Reorganize the order.
+ Do not promote apps via snippets when they already are promoted via
the "New" menu. Also do not promote apps in the same snippet section
more than once.
Part of https://github.com/odoo/odoo/pull/42937
task-2088157
*: website_blog, website_event
This commit adds a "Height" option to sections, allowing them to have a
minimum height of the user's choosing (either full screen height or half
screen height, similar to blog covers). Enabling the full screen option
also allows the user to add a "scroll down button" that will scroll down
to the next section, also similar to blog covers.
As such, the classes doing the corresponding things in website_blog and
website_event have been renamed to reuse the same code.
task-2155710
closesodoo/odoo#41623
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A variable was not used where it should have, breaking the events page
background with the upcoming forum redesign.
closesodoo/odoo#37703
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The local events snippets is an empty HTMLElement which is filled by
JavaScript on page loading. Before this commit, the filled content was
saved in database. This does not create a real problem as the content
is reloaded as soon as the page loads but you can see old events
flickering before the new events are actually loaded.
Now the snippet is cleaned before saving. This also allows to add
default content with a custo so that it is shown during the events
loading (as we are currently doing on odoo.com...).
closesodoo/odoo#35597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
During the event tour, the save button is clicked before the drag and
drop is finished and cause an uncaught exception.
With this commit, an extra trigger is used to check the presence of the
dirty flag that is set when the page is changed and is ready to be
saved.
* portal, sale, website, website_blog, website_crm, website_event,
website_event_sale, website_forum, website_hr_recruitment,
website_sale, website_sale_wishlist
At last, that ugly JS module can be removed. Before this current PR, it
was still used to wait for "page ready", to initialize widgets on page
loading. Now, all can be done thanks to public root and public widgets.
web_editor.base was also still used in tours, which should not be
necessary anymore for the same reason, especially since the tour manager
waits for the public root naturally.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* website_blog, website_crm_partner_assign, website_event,
website_event_track, website_form, website_forum, website_links,
website_mail, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_stock, website_sale_wishlist, website_slides,
website_twitter
While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
With https://github.com/odoo/odoo/commit/ac8b0fcfc5299b5ea62543b8382cb419fed4868e,
the 'country_events' class was renamed to 'oe_country_events'. This was
done correctly for JS animations and snippets but not for the 'Country
Events' option in the customize menu. This made the option useless.
This commit solves the problem by supporting the two classes (as it
is a stable fix).
closesodoo/odoo#30662
* base, portal, website, website_event_sale, website_event_track
- The previous event registration form was not clear on mobile
- Review some layouts to match the new design general idea, using cards
(see forum refactoring of https://github.com/odoo/odoo/pull/29235)
- Use correct bootstrap components (like a menu instead of a breadcrumb
on event pages)
- Review options to be able to disable the left / right column and
choose the exact options you want to appear in them
task-1858034
closesodoo/odoo#30559
This gives the user an overview of the possible actions,
including those he currently does not have installed.
It allows him to quickly install the missing applications
without having to go on the backend.
The commit also improves the existing actions:
- correct handling of the actions deferred
- add some translated terms
PR: #27110
task-1885419
Before this commit it was attached to the form, in case your banner was
customized to have the font-color white, the text modal become white on white.
Now we attach to body, to don't have custom design from parent div.
This commit closes opw-1881280
- JS Modals were not correctly built anymore, their .modal-body element
was duplicated and many without-effect JS lines were introduced (as a
side effect, the form view design was broken when inside modals)
- Tests were changed to make bugs go unnoticed. For example, the media
dialog functionnality was entirely broken because the .modal-dialog
element was not receiving the correct class anymore.
- The JS translation function is _t, not _
- Do not use the <title/> tag as a regular DOM element, it is meant to
be unique, in the <head/> section
- CSS rules were added to the utils.scss file, which is meant to contain
functions and mixins, otherwise, the rule is duplicated in every asset
- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56
- Tests were changed to use [role="dialog"]/footer/header in their
selectors without any reason, this commit restores some of that to
avoid rebase conflicts with the BS4 work.
- ...
Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
Currently there are 3 ways of going out of the modal: clicking cancel
registration, hitting the close button or clicking outside the modal.
The latter one however does not trigger the close event for modals and
therefore buttons of event registration are not reset correctly. This
commit fixes that behavior by preventing to close modal by clicking
outside of it. Buttons should be used and flow is now fixed.
Closes#25174 .
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
10.0 version of 9.0's #24966
opw-1851622
closes#24991
The website_event_questions override EventRegistrationForm's method
on_click and expects the returns is a deferred.
This commit provides a deferred in all instances avoiding an error.
Also what was done in e9454e79 and enables back the Register Now
button if no ticket was selected.
opw-1850527
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
Also if website_event_questions was installed there was an error
preventing an error message to be displayed.
saas-15 version of 9.0's #24966
opw-1851622
closes#24967
Before this commit, you was able to double click on the button when
are in registration flow. In this case, you subscribe 2 times and so
take 2x more seats, what can be annoying when you have a limited room.
In the same time, we fix the form in the form that generate
strange behaviour like some events not bubbled correctly.
The attendee form (into the modal) was inside the registration form.
$'attendee_form).on('submit') obviously failed due to this bad dom.
This commit closes opw-778191
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
* reword various texts in website_event to avoid references to a sell
or checkout process as website_event does not handle sakes;
* if there is only one ticket available, propose to take one by default.
Display Register Now instead of Order Now if tickets are free. Display
an error if the user chooses no tickets in its registration.;
* link in cart for event tickets redirects to event, not product;
* confirm attendees only at invoice payment;
* improve wording, use schedule instead of agenda.
Author Name