Bug
===
Typo error in the name of the action.
Introduced in e2f16573d257257198b1fabb9fe5f619614fb1cf
Task 2186587
closesodoo/odoo#44333
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Event holds a description field that is not displayed nor editable in
frontend. IN this commit we display it in backend form view, allowing
to edit it.
With the upcoming facebook synchronization it allows to directly populate
it with facebook information. See Enterprise PR odoo/enterprise#8058 .
Task ID 1999230
Closes PR #44359
Related: odoo/enterprise#8058
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS 1: remove date fields from event.type.ticket
Coming from old ticket implementation there are several unused fields on
event.type.ticket, notably dates about selling. Indeed tickets defined on
event.type are templates and should not be time bound.
Previously those fields were available on event.type tickets but not propagated
to the event tickets. Now they are not available anymore, simplifying models.
We therefore remove them from event.type.ticket model.
SPECIFICATIONS 2: propagate seats definition from ticket template to tickets
Previously to the global feature this commit is a member of, only ticket name,
product and price were copied from event.type to its events. Description has
been added in a previous commit. In this commit we also propagate maximum
seats availability.
Use case is linked to event.type defining a recurring event in a given
location. As seats availability is known it can be copied on all events
linked to this event type.
SPECIFICATIONS 3: improve naming of event tickets
Before this commit, all tickets of an event were labeled the same way
by default, using simply ``<event_name>``. This is annoying when
having several tickets as they had all the same name.
In this commit we fix that behavior by setting the name
* directly from the ticket template when tickets come from an event.type.
Configuring Standard and VIP tickets on an event type will therefore
give Standard and VIP tickets on event;
* generic 'Registration for <event_name>' when adding manually a new ticket
for an event;
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we add a description on event.type.ticket and event.event.type
models. Its purpose is to have a description to use notably in frontend
(website_event and website_event_sale).
Currently a ticket description is available only in website_event_sale and is
the description_sale field of the ticket product. As we now have tickets
independent from products, we introduce a real description field on ticket
that is either put by hand (event), either coming from the product with
event_sale.
Field is therefore also copied from event type tickets configuration to its
event tickets.
Naming on sale order does not take into account ticket description as we
consider this fields as being used for front-end mainly. SO line descripiton
is now updated as the following
* either we have a description_sale on the product, and SO line description
is 'product.description_sale \n event.display_name';
* either not and SO line description is 'ticket.name \n event.display_name';
LINKS
Task ID 2177281
Community PR #43488
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
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
LINKS
Task ID 2177281
Community PR odoo/odoo#43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we move menu definitions in their own file. It eases views
split and move, as otherwise there are dependencies between files that are
complicated to solve. Better to have menus defined in a main file, and updating
them at will afterwards.
We also improve menus sequences and groups, as some were missing or badly
defined.
Registration tree view is slightly updated to include phone and mobile numbers
as those are used notably for communication. They are hidden by default
like email.
Finally a small tweak of event kanban view is performed, notably to have
a better display with dependencies installed. We ensure all cards have the
same height.
LINKS
Task ID 2177281
Community PR #43488
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Purpose
=======
Improve the attendees management: improve views, actions, (views, actions).
Specifications
==============
In order to allow state management in batch, state field is made editable in
multi edit mode of registrations. That way event managers are able to work in
batch. It required to move some code currently called in custom action-called
methods directly in write. It makes sense to consider that some required code
is called by writing on state field instead of depending on calling the right
method. Indeed there is not much "business" code to move: calling mail
schedulers on confirmation, and putting the closing date when closing.
Event and registration tree views are improved, some fields are now editable
in multi edit mode.
When a user register on a event from website, it will create a sale order and
a partner (the customer of the SO). Set automatically the partner of the
registration to the partner of the sale order.
Task ID 2119333
PR #40949
Purpose
=======
Improve design of the kanban cards in Events.
Specifications
==============
Have more useful information on the kanban record and removed redundant
information
* Display the location of the event
* Remove the duration
* Date should only be in the green block
* Use the same links as before
Task 2170831
PR #43173
Kanban view
===========
- add a field ``sales_total_price`` which contains the total sum of all sale order lines (care about the currency)
- this field is used in ``event_sale``
- display the number of expected and confirmed
- when clicking on these buttons, redirect to the tree view with the correct filter
- display this new field in the kanban view
- display the location instead of the country in the kanban view
Form view
=========
Change the order of the buttons in the header of the event form view
Preview Badge > Contact Attendee > Contact Speaker
Add a note field on the model `event.event`
Search
======
Remove the default filter "Upcoming/Running"
Task #2088538
Purpose
=======
Remove the state on the event and add a stage.
So, we can have more control on the event flow, and we will have less constrains.
Website event
=============
Before
------
People can register for an event if "seats are available" and if the state is "confirmed".
After
-----
People can register for an event if `event_registrations_open` is True,
- Event: seats are available and the event is not finished
- Event sale: One or more ticket has `sale_available` set to True
Task #2088538
Add a domain that limits to the answers belonging an event only on the
attendee form.
Make the width of the event_type_mail_ids 100%
Sort event.registrations by id DESC and Kanban view by name
task-2071337
closesodoo/odoo#37256
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: account
crm
event
fleet
hr_expense
hr_holidays
hr_recruitment
mail
maintenance
mrp
note
project
purchase_requisition
repair
stock_landed_costs
stock_picking_batch
survey
website_event_track
This commit is making sure that the exception activities filters are
only defined where it make sense (i.e. where the system can actually
create an exception activity).
We have therefore removed 'exception activities' filters where the
system won't be creating any.
Task-2056425
closes odoo/odoo#36027
Closes: #36027
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This patch fixes a functional regression introduced in fd3febf7d7. Before that commit, users were able to navigate from a registration to the related event. Now it's impossible, and under some circumstances this confuses the user (i.e. when he comes to the form from an URL that another user shared to him, and there are no breadcrumbs to follow).
Now, users will be able to click in the event and go to its form.
closesodoo/odoo#37834
X-original-commit: eb46c13704bf3aa515fe3a92cc588b762c5e5164
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Stat button "Attendees" of an event now redirects to Kanban view
of attendees (previously redirected to List view).
Task-ID 1935268
closesodoo/odoo#31621
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
purpose of this commit is to show dropdown inside the kanban box with proper UI
By default, bootstrap use Popper.js for dynamic positioning. so, We need to
disable this issue with display static for removing glitch.
expected behaviour:
after applied this commit, kanban dropdown position will be inside of kanban box.
closesodoo/odoo#27150
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
Next to 883c96b781 and recent ribbon widget update some form views
have to be updated. It is best displayed following those rules
* after oe_button_box in order to fix overlapping;
* before image to overlap it cleanly;
LINKS
Task ID : 2032621
PR : #34662
Task
If we use a kanban view to select a record we want to hide those elements:
dropdown boxes, buttons, anchors, some widgets, kanban color.
When it was too much change and used the new attribute
"kanban_view_ref" to explicitly define which view to open in selection_mode.
When also had to create previously unexisting kanban for
fleet.vehicle.model to show name and brand.
Task ID : 1924779
The new visual indicator for exception activities has been added on all
corresponding kanban and list views.
A new filter "Exception Activities" has also been added in the
corresponding search views.
Task 1889379
closesodoo/odoo#31839
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
All activity filters are now invisible in the corresponding search views.
These filters were only used by activity redirection (when clicking on
the activity item in the systray) so we hide them to reduce the noise
for the user.
"My Activity" filter has also been removed, its corresponding domain is
now directly set in the action where it was used.
Task 2036392
PURPOSE
Allow the user to schedule SMS communication on events
SPECIFICATION
In event.event form view:
* rename tab 'Email Schedule' to 'Communication'
* add a selection field at the beginning of event_mail_ids with label 'Send'
and values 'Email' and 'SMS Text Message' (required with default value
'Email');
* add support of SMS template and SMS sending in event communication;
When sending SMS on event registrations, keep a log of what has been sent.
Use mobile or phone field of event registration as both may contain valid
values, like partner model.
Add SMS template data
* Name: Event: Registration (see data)
* Name: Event: Reminder (see data)
Improve registration model
* add a mobile field to the attendees form view: https://nimb.ws/p0VvyS
Technically this task uses the newly-introduced API methods allowing to
send and schedule SMS.
LINKS
Task 1922187
Part of PR #34705
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
Now that the multi company mode is much more easier to
activate, it is needed to display this information on the
tree views, to help people to know on which company is
set some records in list view.
task-1997637
Closes: #3397closesodoo/odoo#33976
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Reorganise the categories of the events sorting them by sequence.
Same behavior as "eCommerce Product categories".
task-1917687
closesodoo/odoo#32010
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Specifications: improve menu organization, search filters and groupby, reorder
filters, update some field labels.
Add search view for event type and make tree views for locations, sponsor
types and track tags editable bottom.
This commit is related to task #1878516 and PR #2649 .
In event_sale it is possible to have one product representing several tickets. But before this commit, on the sale order and invoice the client only saw the name of the product and didn't know which event/ticket they subscribed to.
The goal of this commit is to overwrite that behavior whenever a sale order or invoice line is related to an event ticket, to show the ticket name and event name instead of the product name.
Technically, the following changes have been done:
----------------------------------------
* various: add a method to compute a default name for a SaleOrderLine, based on its product
I added the method because the code to compute the name was duplicated in several places. This will make it more consistent.
Moreover this gives the option for modules to override the method to define a custom name as necessary.
----------------------------------------
* event_sale: compute a consistent description for a SaleOrderLine based on an EventTicket
The description will be the same whether the sale order comes from the front end or the back end. It takes into account the customer language.
The default description will be computed as follow:
1. The ticket name should be the first line of the product description on the SO.
2. The event name should be the second line of the product description on the SO.
To compute the ticket multi-line description we decided to ignore entirely the product name and the product description_sale because they are considered to be replaced by the ticket name and event name.
We also ignore them because the work-flow of creating a new event does not lead to filling them correctly, as the product is created through the event interface.
----------------------------------------
* event_sale: improve sale order line and event registration views
It was possible to select a ticket related to a product before an event was selected.
This is typically the case for tickets defined in an event_type but not in an event.
The ticket field is now hidden until both the product and the event have been selected.
This way we are sure the selected ticket will belong to an event and not an event_type.
We reset the ticket on event change because we don't want the user to be able to select a ticket belonging to the wrong event.
We also improve here the comments of the related on-change methods.
----------------------------------------
* website_event_sale: update views to show ticket name and event name
The standard behavior was to show the product name in several places instead of the sale order line description.
However, for event tickets, we don't want to show the product name, but the ticket name and event name instead.
----------------------------------------
* website_event_sale: add ticket on confirmation page
The ticket name was missing from the registration confirmation page (shown when the ticket is free and/or the user paid with a direct method). This is now fixed.
----------------------------------------
Task: 1837987
PR: 25819
Debauche Stéphane