| Age | Commit message (Collapse) | Author |
|---|
|
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
closes odoo/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
|
|
Notably clean a bit existing event type (data and demo) and add some questions
on conference event type.
LINKS
Task ID 2089156
Community PR #42911
|
|
templates
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.
|
|
|
|
And jump to the App Switcher automatically on module install/upgrade.
That way, we can remove a lot of ir.actions.todo in the code.
|
|
Since we have the app switcher, it makes no sense to jump on a
dashboard view.
Fp request.
|
|
the guidelines.
No change has been made in this commit, only file move and renaming.
|
