Since: a0092d0011
Users can see attendees' selected answers in the registrations list view using
an optional field ("registration_answer_ids").
However, searching on this field is currently not correctly supported as the
"event.registration.answer" model does not implement it (no "_rec_name" and no
"_rec_names_search").
This commit adds a "_rec_names_search" attribute to allow users to search on
both "value_answer_id" and "value_text_box" fields.
This makes it easy to search for all attendees that have filled in a specific
answer, allowing a better organization of the event based on question results.
Task-2868203
closesodoo/odoo#92486
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
changed the start/end date fields to datetime fields, in order to allow more
flexibility for the user and enable them to set a precise point in time at
which ticket sales should start/end, because otherwise ticket sales/end would
always be set at midnight which is not very flexible.
Task-2431440
closesodoo/odoo#65133
Related: odoo/upgrade#2126
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Fix various issues spotted in 13.3 when testing event. Notably
computation of 2many fields coming from template.
SPECIFICATIONS
When updating template on an event, one2many fields should be better managed.
Previous heuristic was
* if event type uses o2m configuration (use_ticket / _schedule / _question)
and has lines
* erase existing lines;
* create new lines based on old one;
This has the drawback of loosing information of what is sent (mail) or
sold (tickets) or answered( questions). Another drawback is that only
types having line are synchronized. This means that if updating several
times the event type you could end up with an XMas configuration with
lines coming from different event types, depending on their o2m configuration.
We choose a better heuristic that should solve this issue
* every time we change type, independently of its use_* field that is used
mainly for UX on the type itself:
* erase existing lines that have not been used yet (no mail sent, no
ticket linked to registrations, no answer linked to registrations)
* create new lines based on old one; if type has no lines, event will
have its old empty line erased as well;
It means that we try to synchronize more the type to the event while keeping
configuration line already used in some registrations.
Also provide some other fixes like deletion restrictions or better domain
for UX purpose. See sub commits for more details.
LINKS
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 645f70cad033083e82a3ef9102c694c331badef9
Co-authored-by: Sebastien Mottet <oms@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
This commit adds a test tour that will fill up two tickets with a few questions
answers and then assert that the answers are correctly saved for each attendee.
This will help ensuring that the new "free text question" feature works
correctly, along with existing "suggestion question".
LINKS
PR #45497
Task ID 2189529
PURPOSE
Allow "free text" questions in the event questions asked to attendees, in
addition to the existing "selection" type.
e.g: "What are your allergies?"
SPECS
The implementation is heavily based on the modelisation we chose for the survey
module since the features become similar in terms of question types and inputs.
- Introduce a 'question_type' that is either 'simple_choice'
(= previous behavior) or 'text_box' that will contain the attendee text
answer.
- Rename the event.answer model to event.question.answer to make it more
obvious that it contains answer "suggestions" to a question of type
'simple_choice'.
- Introduce a 'event.user_input.line' that is an answer to a specific question
for a specific registration.
It works very similarly to 'survey.user_input.line' but it's not contained in
a 'user_input' model, it's directly linked to the registration using a
'user_input_line_ids' o2m field.
The frontend view has been adapted accordingly to display either a selection
input or a textarea based on the question type.
The frontend orm processing now takes in both answer types (id of suggested
answer or text input).
On the backend side, views have been adapted to display event questions and
attendee answers in a more convenient and logical manner.
LINKS
PR #45497
Upgrade PR odoo/upgrade#799
Task ID 2189529
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>
When user register to an event from website, they can answer questions
specific to a given registration or to all registrations. However they
are not correctly parsed and not saved.
Task 2188857
PR #44545
X-original-commit: e27d9b5c4f234f6ce64456c2f52e7cfb0331332f
PURPOSE
Questions asked to attendees are usually attendee specific according to
"statistics". It makes therefore sense to have a field activating the global
question mode that is False by default.
SPECIFICATIONS
Inverse behavior of boolean 'is_individual' and rename it to 'once_per_order'.
By default it is set to False, meaning all questions are individual.
LINKS
TaskID 2162438
Community PR odoo/odoo#44476
Upgrade PR odoo/upgrade#771
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Quentin Mourier <qmo@odoo.com>
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
Aurélien Warnon