Notably
* have tools and helpers in a SurveyCase and let SurveyCommon bet the
one with data;
* remove unnecessary with_user, replaced by standard one;
* move all tools in SurveyCase to help reusing them;
When a random survey does not use all the questions available in a page
because of the random_questions_count field, _get_answers_correctness
was still including them in the skipped category.
This commit ensures that those questions are not included in the result,
and adds a test that checks it.
closesodoo/odoo#47362
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
X-original-commit: 4df43478979766112ae70624deae9c25f40a3349
PURPOSE
Add a "live session" mode for survey that allows the host to interact with its
audience.
He controls the pace of the survey and the audience answers questions one at a
time.
Results for each question can be displayed by the host to adapt his speech in
real time.
A gamification component even allows to give points to the attendees, based on
the quickness of their answer, and create ranking to keep everyone's attention.
SPECIFICATIONS
This whole feature is deeply integrated with survey.
It adds a layer of "survey session" on top if it that gathers attendees and
answers during the lifespan of the session.
The attendee identity is filled in by a special question that is marked as
"Save as user nickname".
If the host has not configured that question or if the user doesn't answer,
they are marked as "Anonymous" in the rankings.
The answer score computation is also altered during the session to take the
speed of the answer into account.
To ease the access to the survey to attendees, we have introduced two new
routes in the survey main controller:
- '/s/123456'
That uses the 6 first characters of the token to give quick access to the
survey and allow typing the URL manually somewhat conveniently.
- '/s' that renders a view that asks the attendee to enter the survey 'code',
which then redirects to the previous route.
This commit also fixes a few bugs:
- A bugged use case with the "enter key" listener.
When the survey is done, we display a "result template" that shows the user
his score and allows him to retry if possible.
When this template is displayed, we don't want to listen to the "enter" key
that allows to submit the survey form.
- We now correctly remove the timer and initialize the result
widget when the user presses 'enter' on the last page / question.
SURVEY SESSION FLOW
HOST point of view:
- On the Survey Form, the host configures:
- "Reward quick answers" that gives more points to attendees if they answer
quickly
- Question Time Limit, on each question, that defines the time limit for
that specific question, allowing to have different (or no) timer for each
question.
- From the Survey Form, the host can start a "live session"
Only one session per survey can be running at a time.
- When he starts the session, the session_state is marked as 'ready', meaning
all attendees landing on the survey page will be part of the session.
- The host will land on a page showing the current number of attendees as well
as the link for the attendees to join that session.
- The host starts the session, activating the first question of this session.
We keep an active reference to the "current_question_id" and use the bus to
trigger an event that will refresh the survey page for all attendees, showing
them the question and allowing them to answer.
- The host gets a "question management screen", from which he can:
- See the current question text & suggested answers
- See the current question timer
- See the number of answers received for the question
- Display the answers of the question (same view as the survey "results"
page, but only for the question)
- Display the ranking of attendees (if "competitive mode" is enabled)
- The host controls the pace of the survey by moving to the next question until
it's the last one of the survey, then ends the current session.
When the session is closed, we mark the answers of the attendees as "done".
- The host lands on a screen where he sees the survey results and the ranking
of all attendees.
ATTENDEE point of view:
- He reaches the survey when a session and open, and gets a screen asking him
to wait until the host decides to start the session.
- When the sessions starts, he's automatically redirected to the first question
(see above).
- If the session is already started when he reaches the link, he lands on the
current question (and NOT on the first one)
- If the host has configured a time limit, the attendee sees the countdown
while he's answering.
- When the attendee answers the question, the screen tells him the answer is
registered and he has to wait for the host to go to the next question, which
will happen automatically.
- If the timer reaches 0 and he has not submitted his answer, it's too late and
he waits for the next one.
- It continues like that until the end of the session.
- At the end of the session, the attendee gets a screen with his global results
(same as a regular scored survey).
PR #43568
Task 1972640
Co-authored-by: David Beguin <dbe@odoo.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
To better understand question type and their input type, we update some of
``survey.question`` ``question_type`` keys :
Type----Old type-----New type
text----free_text----text_box
char----textbox------char_box
Untouched question types: ``numerical_box``, ``date``, ``datetime``,
``simple_choice``, ``multiple_choice``, ``matrix``. Those are already
understandable.
Then ``survey.user_input.line`` ``answer_type`` keys are also updated to
match their question type counterparts
QuestType--------Old type-----New type
text_box---------free_text----text_box
char_box---------text---------char_box
numerical_box----number-------numerical_box
Then ``survey.user_input.line`` fields used to store the value are updated to
propagate the new naming
AnswerLineType----Old field----------New field
text_box----------value_free_text----value_text_box
char_box----------value_text---------value_char_box
numerical_box-----value_number-------value_numerical_box
Untouched answer types and field storing value: ``date``, ``datetime`` still
refer to same question type and use value_date / value_datetime fields.
``simple_choice``, ``multiple_choice`` and ``matrix`` still use ``suggestion``
answer type and ``suggested_answer_id`` (+ ``matrix_row_id``) to store link
to ``survey.question.answer`` records.
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
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: RENAME QUIZ_SCORE ON SURVEY.USER_INPUT
On survey.user_input, quiz_score field to scoring_percentage
``quiz_score`` field name is related to the old "quiz" behavior of surveys
that is replaced by certifications and scoring mechanisms. Let us propagate
the renaming, beginning with a ``scoring_`` prefix.
SPECIFICATIONS: RENAME QUIZZ_PASSED ON SURVEY.USER_INPUT
on survey.user_input, rename quizz_passed field to scoring_success
``quizz_passed`` field name is related to the old "quiz" behavior of surveys
that is replaced by certifications and scoring mechanisms. Let us propagate
the renaming, beginning with a ``scoring_`` prefix.
SPECIFICATIONS: RENAME TOKEN ON SURVEY.USER_INPUT
on survey.user_input, rename token field to access_token
Survey user input model holds two token field. One is used to distinguish
a pool of attempts linked to a given invite: ``invite_token``. The other
one is used to control access to a specific user input. It means that
``invite_token`` indicates a set of user inputs and each of them is accessed
through its own ``token``. To be coherent with other naming in odoo this
latter field is renamed to ``access_token``.
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
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: RENAME THANKS_YOU_MESSAGE ON SURVEY.SURVEY
On survey.survey, rename thanks_you_message to description_done
In this commit we rename thanks_you_message field. Indeed for certifications
or recruitment form, "thank you" is not really the unique content you
would get in a post-survey message. We therefore rename it to description_done
to better indicate its use.
SPECIFICATIONS: RENAME CERTIFICATE ON SURVEY.SURVEY
On survey.survey, rename certificate field to certification
All certification related fields on survey model begin with certification_ .
Only the boolean one telling if a survey is a certification or not is called
certificate. In order to ease grep and ordering it is renamed to certification.
SPECIFICATIONS: RENAME PASSING_SCORE ON SURVEY.SURVEY
on survey.survey, rename passing_score field to scoring_success_min
``passing_score`` field name is not really the best name we could find.
Renaming the field using a ``scoring_`` prefix allow to know this field
is linked to the scoring mechanism.
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
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
In this commit we rename the long standing ``survey.label`` model. Indeed
a label is something before a question, like an input label. Labels in survey
are used for suggested answers and sometimes as rows for matrix answers.
After much thoughts we rename ``survey.label`` to ``survey.question.answer``.
It indicates this model holds answers. Moreover it is namespaced within the
``survey.question`` model name to avoid conflict with user input / user answer
model.
As model naming changes, some fields also evolve. In survey.question model
* ``labels_id`` is renamed to ``suggested_answer_ids`` to indicate it is
used to display suggested values to the user;
* ``labels_id_2`` is renamed to ``matrix_row_ids`` to indicate it is used
to generate the rows of the matrix-type question. A matrix is therefore
done using ``matrix_row_ids`` for rows and ``suggested_answer_ids`` for
columns which seems easier to understand;
In survey.question.answer (old survey.label) model
* ``question_id_2`` is renamed to ``matrix_question_id`` to ease its
understanding, notably that it is used for matrix questions;
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
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
This commit simplifies the answer_tag and question name
by removing the survey_id (uses now only question id) for the most simple cases
Factorise the save and validate survey answers to avoid duplicate code
Review posted submit data :
- process all questions by question type (instead of using form data
(key,value) that needed key parsing and was un-typed)
- regroup answers by questions and adapt all validation and save flow
- remove post data in save and validate question methods
and uses directly the answer(s)
- remove useless input names
The tests have been adapted consequently
Task ID : 1930132
PR #32419
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Stages modification through the clickable statusbar wasn't very intuitive.
By fixing default behavior through states (and corresponding buttons), default user experience is simplified.
3 static states available : draft, open, closed
Form view: navigation through states with buttons
Kanban view: disabled modification of survey state
Task ID : 1949110
closesodoo/odoo#32325
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task #1902306
Purpose
=======
This commit adds certification capabilities to the survey module.
A certification is a survey with the "certification" flag set to true than can be linked
to a certification email template that contains a certification document (PDF).
This template can be edited by the user in the technical settings to customize the certification email/document.
To be able to implement this certification concept, we also have to add scoring mechanisms to surveys.
survey.questions of type 'simple_choice' and 'multiple_choice' now have scores for the suggested answers.
These question scores allow to compute a global score that is used to determine whether the user has successfully
passed the certification or not.
As additional features, we also have:
- A time limit with an interface timer that limits the test to X minutes
When reached, the survey is automatically submitted and unregistered (= unsubmitted) answers are not taken into account.
- A limited number of attempts for the survey/certification
If reached, the user can't take the survey/certification anymore
The 'survey result' layout was adapted accordingly to show the success rate of participants and the correct answers
to the survey questions.
Specs
=======
- Create a new survey :
- Add a description field for the survey
- Options on a survey :
- Passing score : (sum of all good answers) in %
- If No scoring => No passing score, no certificate
- If Scoring with answers => Passing score and can see the answers (can create certificate)
- If Scoring without answers => Passing score but can't review the answers at the end (can create certificate)
- for the questions, if "no scoring" selected, can 't see the option "good answer" and "score" on the questions
- If the 2 others options, can see the options "good answer" and "score" on the questions
- all the types of questions are available for each option.
- Questions
- Add the option correct answer on the multiples questions (one or more good answers)
- Certifications
- If scoring, force "mandatory" for "mutliple choices (1or multiple answers)"
- On the dashboard => visual information that this specific survey is a certification
- Time Limit : The student is informed on the home screen of the survey of the time limit.
The clock start when he clicks on "start survey"
- Template of the certificate : send email with attachment PDF
- Front-end :
- Add some margin
- Replace "Back to survey" with the blue-bar from the portal
- Add a timer (start when the survey starts)
- Add a progress bar (number of section and number of question inside the section)
- Analyse of the results :
- First a global graph with the number of people who''ve participated and passed the test
- Stages of a survey :
- Remove the stage "Permanent"
- 3 stages :
- draft : not on-line but can be tested (with phantom token)
- In progress : on-line
- closed : not on-line
- Who can test a survey : the manager and the user. Add this condition to the phantom token.
Thibault Delavallée