Before this commit, _compute_sale_available would only take into account
the dates to set the field sale_available.
This commit makes it take into account the number of available seats
for the ticket as it is wrong to consider a sold out ticket as
being available for sale.
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
Allow to use UTMs directly in event, notably to be able to sort or make
statistics on registrations.
SPECIFICATIONS
Move all UTMs fields definition to event. In base event module they are
set by hand or through links (when using mass mailing for example).Shared
links with utm bits defined in it allows to track marketing statistics
on registrations.
In event_sale registrations can be linked to a sale order. UTM information
are copied from the sale order to the registration itself. Order defined utm
always erase default one coming from event.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Related: odoo/upgrade#913
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to allow the batch create on those models that may be created
in batch, notably through import.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Origin is a char field holding the registration "source name". Its only use
is to copy the sale order name when registration is linked to a sale order
in event_sale. As we can filter / group / search on sale order or sale order
line directly instead of the origin there is no need to keep this char field.
If necessary to some internal reasons it can simply be added through studio.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Purpose is to have matching names between event type and event to ease code
understanding.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
Upgrade PR odoo/upgrade#912
RATIONALE
Manual onchange is necessary because you spot an issue (or customer complains).
Automatic update through computed feild is only there to try to add missing
pieces of information but cannot decide which is the correct field value to keep.
SPECIFICATIONS
Keep an explicit onchange on partner_id. Rationale : if user explicitly
changes the partner in interface, he wants to update the whole customer
information. If partner_id is updated in code (e.g. updating your personal
information after registeration in website_event_sale) fields with a value
should not be reset as we do not know which one is the correct one.
How it should behave as following
* computed fields based on partner_id should only update missing
information. Indeed automated code cannot decide which information
is more accurate;
* interface should allow to update all customer related information
at once. We consider event users really want to update all fields
Tests are added to ensure behavior is not modified without notice.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFICATIONS: REQUIRED FIELDS
As computed fields are computed after create required attribute cannot be
respected without computing them beforehand. That is why we have some custom
code to compute required fields if not given at create and update the creation
values accordingly.
SPECIFICATIONS: MAIL SCHEDULING
Mail scheduling on event type is modified in this commit. Previously checking
the use_mail_schedule radio button had no effect on event_type_mail_ids field.
It is now reset if unchecked. It is therefore coherent with use_ticket and
event_type_ticket_ids field behavior.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Michaël Mattiello <mcm@odoo.com>
Dealing with newId is sometimes difficult.
closesodoo/odoo#46560
X-original-commit: 416d5ae6f7753c413b6981f9de3d24913943e9c2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When being in edit mode attendees count may be reset temporarily to 0.
Indeed when user change the event_type linked to the event it triggers
the computation of seats. Among those fields seats_expected is used to
display the attendee count in event form view.
In this commit we rewrite the computation in order to work in onchange mode.
It correctly update record in cache instead of rebrowsing event in a compute
and correctly support newid by checking _origin id.
This behavior is probably present since a few versions but as it is not
critical we target the last stable-saas.
closesodoo/odoo#46444
X-original-commit: f858f0432abc97a805e24674990acac510b45e9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Indeed this field is notably based on tickets availability. Reading tickets
products is not necessarily granted to everyone. People reading events should
be able to know if the sale is available or not independently of their access
on product model. Let us therefore use a compute sudo.
Task 2188857
PR #44545
X-original-commit: cfabf12ef888a9dac48cbb19763740e2c65225d5
In the event form view, when only community is installed, kanban state
is not on the right part of the form.
Moreover it should have a default value.
Task 2188857
PR #44545
X-original-commit: 1813f064bdcbc09131197484ed3c075dcba8bcb7
PURPOSE
This field is deprecated. Since its usage was to trigger a warning when
trying to confirm an event and confirming an event is not done anymore,
it has become obsolete.
SPECIFICATION
remove seats_min field and usage from event.event
remove default_registration_min field and usage from event.type
LINKS
Task ID : 2192652
PR : #44938
This commit removes the field twitter_hashtag from event and event_type.
The justification behind this change is that it has been made obsolete
by our social marketing app and our website builder.
Task ID 2191921
Community PR odoo/odoo#44715
Upgrade PR odoo/upgrade#764
Related: odoo/upgrade#764
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
When the auto confirmation flag is set on an event all registrations
must be confirmed by default.
When the auto confirmation flag isn't set the registrations will be
confirmed as soon as the related invoice is paid.
SPECIFICATION
Add a is_paid field in event.registration which will be updated in a
method as soon as the related invoice is paid. This field is used to
display a ribbon on the registration to emphasize its payment status.
LINKS
task ID : 2093336
PR : #43420
PURPOSE
Improve the integration between event and sale, by adding additional information
on both the sale order and the event registration views.
SPECIFICATIONS
- Add a stat button on the registration form linking to the related
sale order instead of a link in the form itself.
- Add a stat button on the sale order showing the registrations count
related to this sale order.
- When changing the ticket type on an attendee it displays an exception
activity on the sale order in order to warn the responsible for taking
action about it.
LINKS
task ID : 2093336
PR : #43420
PURPOSE
- In order to get an overview over events, add a graph view grouped by
event name and measure by seats available.
- Before this commit you had to install event_sale to see the popup window
in the barcode interface when scanning an attendee. With this commit you'll
see the popup even when event_sale is not installed.
SPECIFICATION
- Add the minimal information about the registration in the event module
and overrides it in the event_sale module to add the necessary informations.
That makes the window popup appear everytime when scanning an attendee.
- Add a "is_ongoing" field on event model to use it as a filter in
event_barcode.
LINKS
Task ID : 2093336
PR : #43420
Enterprise PR : odoo/enterprise#7760
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 make a quixotic attempt to clean call chain implied by
making registrations online, either in event frontend (website_event) or
with eCommerce inclusion (website_event_sale). Purpose is to get rid of some
preparation and data management methods to handle most of the code directly
at CRUD level whenever it makes sense.
We notably
* move at create and write level support of partner_id update: updating
its name / email / phone / mobile;
* move at create and write level support of sale_order-id update: updating
event, ticket, partner;
Using that and some code cleaning some methods are removed and call chain
is a bit reduced.
LINKS
Task ID 2177281
Community PR #43488
Since 412ff994f1 seats_max field of event cannot be modified as it
is always readonly. It should instead not be readonly as we consider people
could change it whenever they want.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
Currently when changing category of an event, its category mail scheduling
is copied onto the event even if the category does not enforce its use.
We have to check the category use_mail_schedule field before computing
the new event mail schedulers.
In this commit we also lessen default schedulers from 3 to 2 in order to
still help people using them without bloating too much event creation.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
In this commit we prepare future event model changes by reordering removing
unnecessary parameters definitions, notably readonly set to False as it is
the default value. Those parameters notably come from 412ff994f1 .
Some reordering is also done in order to better understand future pre / post
change model organization.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
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
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
Use _tz_get for tz-based selection fields from partner as it smartly order
available timezones.
Remove a strange "event.confirm" wizard that calls an unexisting method,
is not reachable and is actually completely unnecessary.
Reorganize ticket fields to ease future improvements and perform some
public -> private method cleaning.
Remove duplicated code in event_sale.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
prout
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
As event model grow in complexity and features, it is easier to find its
way through the application with having registration model lying in its
own file to separate it from event-specific models (event.type, event.event).
Ticket (event_sale) and sponsor (website_event_track) models are also extracted
in their own file.
LINKS
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Currently event_count is a computed field with a shortcut in computation for
non event user. It is better to directly limit this field to the event_user
group instead.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Currently an onchange on event type copy the mail schedulers information from
event type to the event. In order to ease inheritance, some white listed
attributes are directly copied using direct getter (line[attribute], see code
for clarity). However mail and sms templates are many2one fields and the
id should be copied, not the browse record.
There is no issue when the onchange is trigered from interface because a
mapping is done. However when calling the onchange in code there is a crash
as the record is directly given to write.
closesodoo/odoo#42990
X-original-commit: 09c6747ea2de108cf512091b7837a71d4ea4662a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The cron will move every ended events in the next "ended stage"
We inherit from `ir.autovacuum`, so the method `power_on` is called one time per day.
Task #2088538
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
PURPOSE
This commit 62ac23f0b9 introduced SMS capabilities on for
event.type.mail and event.mail models.
Values of event_type_mail_ids on event.type are supposed to be copied to
event_mail_ids on event.event when changing the event_type_id of an event.
There are however 2 issues with that integration:
- The 'notification_type' field was not correctly set on default
event_type_mail_ids on event.type;
- The 'notification_type' and 'sms_template' fields were not copied from
event_type_mail_ids to event_mail_ids;
LINKS
PR #39892
Task ID 2115792
closesodoo/odoo#41736
X-original-commit: 3fd66d844aa66ca8d54223071c787974e6c88c94
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Fixes https://github.com/odoo/odoo/pull/39583
This commit adds a default value for event_count
Assigning default value for non-stored compute fields is required in 13.0
closesodoo/odoo#39974
X-original-commit: 9ca72b98f54d7686c0e6019870b40f14dbdd2881
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Create an event
- Add a mail reminder for it
- Run the mail scheduler manually
- Duplicate the event
The mail reminder is sent on the duplicate too.
This commit remove the field `mail_sent` from duplicating.
OPW-2117343
closesodoo/odoo#39777
X-original-commit: 7fede2c0360f72410ac36f5d706ac5c7c18b7c7d
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Have an event in Mexico timezone
As a begin date, choose something in the morning
As a end date, choose 18:00 in that timezone (or later)
in the same day
The end date will be written as the day after at 00:00 in UTC
Before this commit, the event was considered taking more than one day
Also, the rendering on the website took the wrong widget, and did not
transform the UTC dates into their TZ value
After this commit, the event is considered taking place in the same day
The rendering on the website is correct
OPW 2087828
closesodoo/odoo#39060
X-original-commit: 4514ff30e9cc218474dda4519e36cfc983e49fc8
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
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
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
qmo-odoo