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 changed some order of fields in
attendees form view, changes are listed below,
- moved `partner_id` field next to `event_ticket_id` and
made this field editable and trackable, this change had done because
currently this is the first field you see and it currently
looks like this is the person that's coming.
- moved `visitor_id` field below `mobile` field, so that even
in debug mode, Attendee Name is the "primary" field.
Apart from that right now if there are attendee data (name/email/phone)
and when we update the partner_id these attendee data will be erased
and updated as the new partner's information.
In this commit we are improving this, if there is any attendee data
it will not get erased while partner_id is updated. Attendee data
will get updated only if name/email/phone fields are empty.
TaskID-2670765
Part-of: odoo/odoo#79166
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 seats_availability selection field into a boolean field
and rename it to seats_limited for consistency.
SPECIFICATION
Change all the tests accordingly.
Task ID : 2198660
PR : #46659
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>
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
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
=======
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
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>
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
Some tests had to be adapted because they relied on the buggy behavior:
this was particularly the case when they tried to write on readonly
related fields.
closesodoo/odoo#32460
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
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
Fix a14bdbd4be made event correctly use
default_auto_confirmation key. However since commit bf82638bb0
tests were also not correctly using the ir values key.
This commit should fix all use of that key. Maybe.
[FIX] event: emails: format of date: 31 Janvier instead of '20160131T1010110'
[IMP] event: better emails (button to zoom to event, cleaner text, show
organizer phone and email)
* 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
Among others small improvements :
- [event] remove automatic logging of new registrations on event; for big events
it produces only noise
- [event_sale] fix product creation from event management; better display of
address and date of the event
- [website_event_track] add a cancel state on the track model. The stat button
on the event shows only not-canceled state. Also added some tips.
event:
- added tip
- default subscription/reminder/thanks templates for registrations are now using
the reply_to defined on the event
- fixed check of available seats: use seats_availability field, unlimited events
should never trigger the constraint
- added a sequence on scheduled emails on events
- config: wording improvements
- various improvements in event, registration, event_mail and event_report views
event_sale:
- removed override of seats_max: should not depend on available seats in
tickets. Indeed you may have less available places than the sum of seats for
each ticket type, for example if you have 0-10 VIP and 0-20 Standard tickets
for a 20-seats event.
- removed a duplicated view override
- added a seats_availability field on tickets, same meaning as on event.
- improved event form view: registration tab is now replaced by the tickets tab
when tickets are used
website_event:
- better management of sold-out event in the front-end, when doing registrations
website_event_sale:
- removed register link on the event kanban view. There is no need to to from
the back-end to the front-end from the kanban view. The published button on the
event form view already allows to go to the front-end view on the event
- better management of sold-out event in the front-end, when doing registrations
- fixed a template that was in customize and should not
website_event_track:
- wording improvements
- small improvements in the front-end of tracks
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
Attendees are created and deleted on changing the quantity from the cart.
Added sale_order_id and sale_order_line_id fields on registrations, allowing
to find the order and the order line that created the registration without
to rely on origin and ticket.
Also fixed check_auto_confirmation, now in multi mode to avoid issues due to
the specific behavior of api.one.
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.
Registration are now for one attendee only. When buying several seats for an event
you have now one registration for each attendee.
event: nb_register field is removed; as well as unnecessary user_id and it subscribe /
unsubscribe behavior. Also slighly cleaned some views.
event_sale: do not auto confirm registrations linked to a draft sale order. Note: strange
origin is a char field, not a sale_order_id. Added a small wizard to edit attendees
data when confirming a sale order containing event related lines.
website_event: when buying free tickets, ask for attendee details. Added template,
controllers to handle that behavior.
website_event_sale: when buying tickets, ask for attendee details. Events ecommerce
should be better integrated with online events, using inheritance to add details
instead of being very different.
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.
Ivan Yelizariev