Add default date_begin and date_end when creating an event.
To avoid having weird time (like 11:23) we round date_begin
to the nearest 30 minutes range and the date_end is set to
the next day of date_begin.
So for example if now is "2022-06-30 10:12" then:
date_begin = "2022-06-30 10:30" and date_end = "2022-07-01 10:30"
task-2845417
Part-of: odoo/odoo#91883
Purpose is to have a common event class for users and useful stuff (customers,
products, ...) but lessen usage of common test data through sub modules.
Indeed having a "global event type" test data updated in various addons is
actually complicated to maintain.
Sub add-ons are updated to use mainly the ``EventCase`` test class holding
users and side data. Data specific to those modules (event type with some
specific configuration notably) is created and used in tests in the given
module only, and not through generic event_type_complex and event_0 test
data anymore.
With this commit tests are more localized to their add-on and modifying data
in a given add-on has less chances to have unwanted side effect in other event
submodules unit tests.
Task-2703285 (Event performance improvements)
Task-2703289 (Event testing and coverage)
Part-of: odoo/odoo#81068
In this commit we have removed the `date_open`
field from the model `event.registration` as it
is a duplicate of the `create_date`.
TaskID-2670765
Part-of: odoo/odoo#79166
Purpose
=======
A new module "Event Social" will be added in the enterprise PR. This
new module will use a new template type, the "Social Post Template"
adding one more column in the communication tab...
We want to have only one column to select the template (Mail, SMS or
Post template) and therefor we need to use a reference field.
Technical
=========
As we can not set a domain on a reference field, we added a context key
and in the `_name_search` of the `mail/sms.template` we filter with the
domain we want if the key exists.
Links
=====
Task-2127615
See odoo/odoo/pull/46304
See odoo/enterprise/pull/7701
See odoo/upgrade/pull/848
Purpose
=======
Clean the ACLs related to the Event application.
Add a new group to manage the registration in the entrance of an event. This
group should not be able to modify or remove records in Event but should be
able to create and manage the registrations.
Specifications
==============
Now, there are 3 event groups
* ``Registration Desk User``, who can manage the registrations and
read all event-related information;
* ``Event User`` who can create event, sponsor, ticket... His role is
to globally handle events on a day-to-day basis;
* ``Event Administrator`` who can create event type, sponsor type,
ticket type... His role is to manage the way events are managed withint
its company:
Each group implies all previous groups.
Compared to previous event users gain a lot of rules, allowing to update
records like tickets, registrations, ... Low-end event users should now
use the registration desk group.
Links
=====
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
Purpose of this commit is to add some tests related to event_type to event
configuration. Indeed changing a type on an event may change its sub models
(mails, tickets, questions). Asserting current behavior is necessary before
tweaking behavior considered as to be improved.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 6fb42e70164bab05681b11f1e76e320db0266445
In this commit we add some tests related to sale order / event registrations
synchronization, notably
* registrations automatically created when _update_registrations of an SO
line is called, for example at SO confirmation;
* using the registration editor;
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
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 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
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>
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
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
As some event models (event.type and event.ticket notably) are about to
be modified let us add some tests to avoid regressions.
Security tests are also moved in their own file. Some internals tests defined
in event_sale are also moved in their own file. That way we avoid bloating
files with unrelated tests. Future commits will add tests for event and
event.type models.
LINKS
Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066
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
Clean existing tests: lessen data / variables, try to remove unnecessary
tests or merge duplicates.
Add new tests, notably event type configuration copy onto event records
is not well tested. Event computed fields are also more tested.
Some access tests are added, more a base for future addition as only a few
use cases are covered.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
PURPOSE
Allow the user to schedule SMS communication on events
SPECIFICATIONS
In order to add tests this commit performs a quick cleaning of event common
class to speedup and prepare new tests.
Containing
* move data creation in class and use savepoint;
* move registration creation in its own method to allow calling it if
necessary;
* clean some unnecessary variables.
LINKS
Task 1922187
Part of PR #34705
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
* Limitate rights of event user to reading an event
Event user should not be able to create events. Its rights should be limited
to reading events, creating and updating registrations. Only event managers
are allowed to create and modify events.
* Sudo access on ir.values in event config settings
Configuring events imply modifying auto confirmation parameter which is stored
into an ir.values. As this model is limited to values with user_id = uid we
have to sudo the access here as it is not a user-defined value.
* Add some tests for the various fixed issues
This commit adds a way to configure scheduled emails on events. It replaces
existing automatic emails at confirmation and subscription. It proposes to
configure some schedulers, based on subscription or event, using a template
and a configurable timedelta.
A cron is added that regularly checks for event mailing schedulers to execute
and launch them. The granularity of send emails is therefore limited to the
granularity of the cron, aka 1 hour.
[TEST] Added tests for this feature.
Also cleaned a bit event, country_id is now a pure related instead
of a computed field trying to be a related. Also removed default templates
on event category. Configuration in the event itself should be easy
enough for most use cases.
automatically confirm events. In a simple flow it is usefull to automatically
confirm event and registrations.
[TEST] event: moved draft2done test into a unittest, easier to finely tune
in order to test the auto confirm option. Moreover this gives a basis to
further add python tests in the module. Hooray.
Jérémy Hennecart (jeh)