* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Currently, in demo data (or data) of some surveys, there are records of
'survey.question' having 'is_page' field value as true and 'question_type'
is not defined. When question type is not defined, default value
'simple_choice' is assigned to the 'question_type' field. Now when we
create a live session of that survey and go to the page, it tries to read
the data for bar chart but data is not available (undefined) and the
traceback is thrown. This happens because question types 'simple_choice'
and 'multiple_choice') are expected to load a bar chart.
It used to work before commit[1] where default 'question_type' value was
being set to 'text_box' (so attempt to load bar chart was not made).
This commit improves the behavior by adapting data/demo data/test cases
and by adding a python constraint that prevents question creation of
page type if there is a question type set, and compute `question_type`
based on `is_page` field. Now that we have python constraint and a
compute method, we no longer need the `default_get` method, so it is
also removed.
commit[1] - https://github.com/odoo/odoo/commit/1fb99d79b1567d4c150dc07f309ce54a3beea8e3
taskID-2841582
closesodoo/odoo#93414
Related: odoo/enterprise#28305
Related: odoo/upgrade#3600
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS
``question_ids`` field name is quite difficult to understand as we wonder why
there is such a field on user input model. As its purpose is to store questions
user has to answer (randomly chosen or all chosen) let us rename it to
``predefined_question_ids``.
Moreover starting from now on if it is now given at create it is automatically
computed. Classic flows go through ``survey._create_answer()`` method that
prepares them accordingly. However tests or demo data do not necessarily go
through that method and it makes scoring fail (notably) if people forget
to define them.
Let us automatically generate them at user input create if not given.
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
Task #1902306
Purpose
=======
The "page" concept is now only present in the user interface.
Surveys are split in "sections" that have two purposes:
- Organizing a (long) survey/certification
- Allow to pick a random questions count for that section (more information here after)
On the user interface, based on the questions_layout field, surveys are displayed:
- On a single page, where sections still appear but are only used as visual separations
- On multiple pages, having one page per section (this matches the previous behavior)
- On multiple pages, having one page per *question*
On top of that page concept, this commit added randomization for the survey questions.
The randomization mechanism will take X questions per section of the survey.
The survey.user_input is initialized with the selected questions to be sure to keep that
set of questions and avoid showing a new set of questions every time the user refreshes the page.
This also allows to easilly go back and know which question we have to show.
Florian Charlier