* = event, event_booth, website_event_questions
We used to provide data for the event templates (event.type) to provide a basic
configuration to play with. However, they are not much helpful, and sometimes
can confuse the users.
This commit removes the data records for the event templates, and on the
m2o field on event, now we let users create/edit them on the fly so that
they can explore the feature by themselves.
We have also added demo data to the 'Exhibition' and 'Sport' templates,
having booths and questions, respectively. Along with that, we have added
relevant data to the demo events where both templates were used; and set
auto-confirm to be false by default when creating a new event template.
taskID-2854123
closesodoo/odoo#99421
Related: odoo/upgrade#3849
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the price and the event are the same, nothing allows
ordering tickets in event_sale. Therefore, add a sequence
number and handle widget to the tickets (in data as well).
Also do it for ticket templates. Also, order the tickets
(on events and templates) by name before id.
Since event type tickets are not linked to any event, the
order does not include the event_id. However, event event
tickets are, and if they appear in the same list / reporting
someday, it makes sense to order them by event_id first.
In event_sale, we make sure the price is also in the order.
As the price is in the copied fields on the event when
using an event template, we add the price on the event
type tickets ordering to align with the event event tickets.
Add default value to sequence and sequence number to data
for event.type model. They were sequenced but demo data had
none, hence not really ordered.
We also add the id in the event.event _order value, otherwise
when ordering on the event (for instance ordering on event_id
for event.event.tickets), the order is random for events
having the same date_begin. We prevent this from happening.
Also make description optional hide on event types.
Task-2997391
closesodoo/odoo#101384
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Change event onboarding rainbow message to something more relevant. Default
message is considered as less user friendly than the new one.
Before this commit the category_id for a tag had no label displayed. We choose
to wrap the category_id field inside a group so that field labels shows up.
In settings, wrap the tag_ids inside a div.o_setting_right_pane so we can have
the left border displayed correctly, like most fields in settings.
Finally remove "Online" template from the event_data since it acts like a
dummy type without pre-defined data.
Task 2257884
closesodoo/odoo#52472
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Change the event form view to improve its usability and make it clearer.
SPECIFICATIONS
- Change some stats buttons icons
- Change order of the fields and put the range date field in second
place since it's a mandatory field.
LINKS
Task ID : 2198660
PR : #46659
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
In this commit we clean some event.type definitions. Indeed there are several
of them without any real use, demo as well as data. It is more important to
have fine-tuned demo and data than a lot of unused or generic demo.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
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
Currently even module logs a message in all employee channel with a
message telling the module has been installed. It is not interesting
as it gives no real information and is not interesting for users that
do not use event module and/or do not have access to it.
Let us remove that data.
This commit adds several event categories as data in event modules. The
purpose is to help people using the event application with some help
on event configuration done through event categories.
This commit improve event.type (Event Categories) model and views in order
to ease event configuration through more detailed categories. The purpose
is to be able to define categories holding default data for website,
tickets, attendee mailing, ... Choosing a category on a new event takes
those default values to help users creating finely-tuned events.
Main configuration on event.type is
* auto confirmation, replacing the old system-wide auto confirmation
parameter
* seats limitation
* location: online events, timezone
* communication: reply-to email address, twitter hashtag, automated
mailing of attendees
* ticketing
* website parameters: display on website, display tracks, allow track
proposal
* question to attendees
The purpose of this commit is to handle code execution only in server
action and delegate schedule management to ir_cron model.
ir.cron model now inherits from ir.actions.server. Fields model, function
and args are removed as well as the logic to handle them. There is no
more code manipulation and evaluation in ir_cron, only a call to the run
method of ir.actions.server.
Cron form view use server action form view as primary view. This way
automated actions use the same base form as server actions with
cron details added.
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo for reviewing.
Pratik Raval