Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Add a domain on question_id. Its event should be the same as registration
event. Otherwise when editing in backend all questions are available while
only those related to the registration's event should be.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 25d53430f32598a5db65be807756182d2063b3ee
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 necessary views and actions for users to be able to
conveniently analyze attendees answers.
- A graph view showing counts of each suggestions for simple_choice questions
- A pivot view showing registrations vs answers for simple_choice questions
- A tree view showing textual answers values for text_box questions
(Tree view is also available for simple_choice)
LINKS
PR #45497
Task 2189529
When applying an event.category on an event.event, we copy the event.questions
from the event.type, but we don't immediately copy the answers associated to
these questions.
This was not done for technical reasons, we were limited by the JS framework.
Since #46807
We now correctly handle nested o2m when triggering compute/onchange.
This commit cleans the code by correctly copying the answers along with the
questions when changing the event.type of an event.event.
LINKS
PR #45497
Task 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>
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
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
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Let's consider an event category EC with questions/answers configured on it.
When the category EC were added to an event, the questions were successfully
added to the event, but all the question answers were blank.
ps: odoo doesn't support multi levels of onchange i.e. the values of answer_ids
inside the values of question_ids in this specific case.
opw:744062
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
In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..
On the ecommerce, when ordering a place for an event,
and answering to an event.registration.answer,
it wasn't possible to delete the quotation line
(missing ON DELETE CASCADE)
opw-631619
Martin Trigaux