RATIONALE
Merge two phone-related field on registration as they overlap. Having only
one is sufficient for contact-oriented model like registration.
SPECIFICATIONS
Registration model currently holds two phone field, phone and mobile. This
leads to having records with sometimes phone, sometimes mobile being filled.
This makes phone flows not easy: we have to define fallbacks (use phone or
mobile), data is not always synchronized, ... in the end what event users
need is one phone field to be able to communicate with attendees. Having
only one field is sufficient and simplifies the model.
Keep only one phone field, instead of two. Merge phone and mobile into a single
one, keeping phone as first value when having both available e.g. when
synchronizing with the partner.
Task-3366899
Part-of: odoo/odoo#128232
Co-authored-by: "Jeremy Hennecart" <jeh@odoo.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
CHEVRONS
Add chevrons to the event booth front-end process. A template is added
to be called in booth choice and form views, and the one called from js
is also updated with chevrons. The code is minimized, and fits for the
three current steps only.
- Booth Selection
- Contact Details
- Confirmed / Payment
CLICKABLE + REMEMBER BOOTH CHOICE
To ease the process of changing booth / booking another one, the
"Booth Selection" chevron is clickable and highlighted on hovering.
Also, it will keep booth_ids and booth_category_id url parameters.
From that, the category will be selected and the booth_ids checked
(if available), the first time the selection screen is loaded (once
the user goes between booth categories, it will not remember booths
any more and not preselect any) In order to do so, the arguments are
added to the appropriate methods in controller (and overrides), with
particular attention to match format. (string vs int...)
SCSS
Styling is added in website_event_booth.scss. Cautions are taken to
ensure proper chevrons coloring even with edited theme colors.
DYNAMIC WORDING
Instead of 'confirmed', 'payment' is used in chevrons, and "Go to
payment" instead of "Book my Booths" in the contact details form,
if one of the following is true (~ new boolean value 'use_payment_step'):
- In selection screen: at least one category is not free
- In Contact Details screen: the chosen booth is not free
- In both Selection and Contact screens: if cart has non null total
amount. (this is the current logic used to redirect to payment)
CONTROLLER REORGANIZATION
In order to add the "use_payment_step" to the rendering values,
the routes of those views now have their value preparation methods,
making them easily overriden (done while maintaining guidelines)
OTHER CHANGES
- Some wording on the form
- Hide sponsors in the booth booking flow
- All views have the same space between chevrons and content (48px)
- Tour is updated to match new wording.
- New map icon and simple link button to display the map of booths.
- No more justify content for display of booth categories
- unglue the rows of booths vertically
- Remove the use of jquery where possible in worked areas.
- Rename activeType to clearer activeBoothCategoryId in JS
Task-2821962
closesodoo/odoo#114052
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
{sale, exhibitor, sale_exhibitor}
Specification:
- Currently, when a user books an event, it redirects to the checkout page;
however, if the user already has some items in their cart, they will appear
at the checkout; if they need to remove them, they must go to the cart page.
It's better to redirect users to the cart page rather than the checkout page.
- When a user enters the booth registration value, it fills the fields name,
email, phone, and mobile, but when the user enters the address of the
order, the same fields are filled by the user, so it is preferred that the
fields value entered in booth registration appears in the address of the
order as well.
This commit done following changes:
- Redirect the review order instead of the checkout order when booking
the event booth.
- By adding the partner to the order, it can propagate the values of the
fields name, phone, and email.
- When a partner is created in the website event booth, the email address is
stored in the name. This commit passes the name and email instead of the
email address so that the partner can be stored with the name.
- If the contact does not have a name or phone number, it will set the
sponsor's name or phone number as the contact.
- Adaptations to the tour to accommodate the above changes
task-3098295
closesodoo/odoo#112525
X-original-commit: ca2bac512000674d1ee55ed3151bbdace2311234
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
PURPOSE
Before this commit when confirming a registration on the frontend the form
was directly sent to the controller and the user was redirected on the
success page if no errors.
After this commit an ajax call is made after validating the form and the
success page is directly loaded from the response... there is no redirect
anymore.
This way of displaying the success page prevent using the link generated
before by another user and getting private information about the booth's
renter.
Two more advantages are that it's easier to maintain and it's slightly
faster than before since the whole page isn't reloaded.
LINKS
Task-2635461
PR : odoo/odoo#77081
PURPOSE
This module enables the Booths registration on the frontend by adding
a dedicated page on the related event.
The user will have to first select a booth category and then select one
or more booths to book. He will then be asked to provide his contact informations.
The booths will directly be set to unavailable... First come, first served.
LINKS
Task-2318655
Closes : odoo/odoo#71104
