Purpose is notably to display last survey attempt as "Date of certification"
instead of first one. We therefore set an _order on survey.user_input model
(user participation to a survey) as create_date desc. When several attempts
are made the last one will be considered when doing a search with limit=1.
Closes#61362
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Unanswered questions or sections are now hidden in the survey review mode.
Only the question answered by the user will be visible.
If the survey was done during a session, the users will see their own answers,
even if the theme they selected was not the most voted one (in case of
conditional questions).
To get the questions to display :
- questions that have been answered
- + the ones that should have been answered = active questions
In session, active questions are based on most voted answers)
This commit also fixes the randomized questions handling in most voted answers,
as copied predefined questions where <NewIds> and those was not usable in
some templates.
Task ID: 2230980
X-original-commit: 8ca79727d5a93b91746c1e63d59d08550417906c
Before this commit, when computing the result graph data in the survey finished
page, a user answer for a question with no correct answer was counted twice,
once as correct, once as incorrect, as :
correct_answer == question_correct_answer == none
After this commit, we count an answer as correct only if question has a correct
answer.
Task ID: 2176630
closesodoo/odoo#54755
X-original-commit: 74a00111908556bce10ea3a5e748f5a5c81f6a40
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes timer related issues on survey flows, for both regulars
surveys and survey sessions.
The timer was unreliable in its completion by a whole second, which had not a
big impact at the user level but could make some tests fail (randomly).
Side changes from this commit:
- Reduced delays in the survey session tests to speed up testing
- Removed some timer flickering on survey views
LINKS
Task 2230526
Runbot error ID 535
closesodoo/odoo#49178
X-original-commit: 15c72aec71d42624685fb0fc9df25279c7855310
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously only the question_types 'simple_choice' and 'multiple_choice' were
scoreable and could have "correct" answer(s).
In this commit we change this behavior so that question_types 'numerical_box',
'date', and 'datetime' can also have a "correct" answer and an associated
answer_score.
Task ID: 2061937
Community PR #43014
Upgrade PR odoo/upgrade#835
Purpose
=======
This commit adds a new survey mode : conditional questions. A conditional
question is a question that will be displayed to the user only if the user
selects a specific answer from another previous question i.e. question B is
displayed if user answers 'Choice 1' at question A.
Specifications
==============
There are 2 different ways to handle conditional questions.
* For one_page and page_per_section survey layout: conditional management is
done mainly at frontend side. The idea is to be able to load all the
questions of the section, hide the conditional questions and display them
dynamically on answer check.
E.g.: If user checks answer 'Choice 1' from question A, question B is
displayed immediately.
If question B is on section 2 and survey layout is set to section per page,
question B will be displayed immediately on next page template load.
Indeed, on each page load, server sends all the selected answers and the
template displays the conditional question depending on the already
elected answers;
* For page_per_question survey layout: conditional management is done mainly
at backend side. The idea is to find on each page the next question to
display depending on:
* navigation direction (next - previous)
* already selected answers and conditional question dependance
* survey questions sequence
E.g.: If questions survey are Question A, B and C and question B must be
displayed if answer 'Choice 1' from question A is selected.
At Question A, if user select 'Choice 1' and goes next: display B
At Question B, no matter the answer, if user goes next: display C
At Question B, no matter the answer, if user goes prev: display A
At Question A, if user select 'Choice 2' and goes next: display C
At Question C, no matter the answer, if user goes next: End survey
At Question C, if user has selected 'Choice 1' at question A and goes prev -> B
At Question C, if user has selected 'Choice 2' at question A and goes prev -> A
In both modes answers on questions that should not have been displayed to the
user depending on the previous selected answers are cleared.
E.g. : User checks 'choice 1' from question A, then complete question B.
Then user unchecks 'choice 1' -> answer on question B is cleared.
Ignore conditional configuration :
* during survey session, to avoid having different users answering different
questions on the same session. That would be confusing for users to see
questions on presenter screen that they didn't have the opportunity to
answer;
* if survey questions selection is random, because it will not display
conditional questions if they are not kept by randomization. To avoid
confusion, conditional configuration is simply ignored, not unset, so the
user can still reactivate it without having to reconfigure everything.
Remove questions that should not have been displayed to the user (depending of
the made choices) in scoring computation and print layout.
--> Inactives questions are removed from predefined questions when user finish
the survey.
E.g.: If the user selects first path on 2, he will never see second path.
If the user answers correctly to all question of first path, he should have
100%, instead of 50%, even if questions of path 2 are mandatory and scored.
Link
====
Task ID: 23509
PR #44950
PURPOSE
Improve layouts and usability for the host screens when using survey sessions.
We focus on the "host" screens, as the attendee screen is based on regular
survey flows/design.
SPECS
In short: copy mentimeter "wow effect".
Main points:
- Remove the "question" container (keep only "Results/Ranking")
- Remove the tabs concept, views are displayed in full screen
- Purpose is to have a "clean view"
- The display must be "full screen" with only relevant info
- Enable a easy keyboard navigation with left/right keyboard arrows
and spacebar
- Switching from results to ranking to next question is always linear
(next/previous instead of tabs)
- Improve charts
- Remove the pie chart : make bar charts instead for simple / multiple
choices
- Show the chart results "as people answer to it"
Only if question is not scored, otherwise show when all answers are
received / when user goes to "next"
- For free text/date/datetime: show small bubbles with attendees answers
- Add resize, fade in/out, ... animations for "wow effect"
LINKS
PR #45111
Upgrade PR odoo/upgrade#774
Task 2191924
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>
Because 0 evaluates as False in "if" statements, generalized answer_type
constraint check logic would not allow user to submit a survey with 0
as a numerical value. This commit fixes this issue by explicitly allowing
this case.
Triggered by task ID 2061937 (improve scoring in surveys)
PR #44205
PURPOSE
To have a better UX, the transition between questions in a survey should not
be done by loading another page, but by loading next questions in AJAX.
This will allow to fade out / fade in the next question and improve the user
experience, as well as prepare the work for the complete survey redesign.
SPECIFICATIONS
General
=======
This commit refactors the way the questions are loaded.
To go to next question(s), instead of redirecting to a new page containing
the next question(s), the submit process is loading the next question(s)
using ajax. The template of the question is prepared at server side and is
given in html string to the client that display the next question in a smooth
transition (fade in / fade out).
This commit includes also the start and the end screen of the survey inside
the survey form in order to perform smooth transition between start screen
and first question(s) and between last question(s) and end screen.
Only one master template (survey form) is now used to display every part of
the survey : start + questions + end screens.
The answer_done error is now handled by the _prepare_survey_data itself.
If the user wants to display an already_done survey, the returned template
is the end screen.
This commit handles page transition for the survey results. When submitting
survey, the survey result widget is initialized and attached to the survey
result section.
A new route has been added : /survey/begin/.
If the user arrives on start screen, the state is 'New'. Once the user clicks
on Start button, an rpc call is made to survey/begin that will call the
survey_prepare_data to render the first question page and set the state to
in_progress and the start_datetime of the answer.
Validation
==========
Add the validation of all types of questions directly in the frontend.
This allows to reduce the latency before the survey is validated and was
necessary to go along with our new fade out / fade in mechanism.
The client does not need to wait the validation answer from the server to
display validation error messages.
The current questions are only faded out if the frontend validation has passed.
The server still makes this validation before submitting answers and loading
next question(s) to avoid direct rpc calls that would mess up the answers.
Error messages are now displayed with a slide down transition, for a wonderful
wow effect !
Timer
=====
As the survey form works with ajax to display start screen, question(s) and
end page, the timer has to be started only after the start screen.
This commit display and start the timer only after start survey button is
clicked.
Breadcrumb
==========
As the survey form now works in ajax to display in same page start screen,
question(s) and end page screen, the breadcrumb has to be controlled not only
on page loading but also manually between transition from a screen to another.
To ease the breadcrumb management, breadcrumb is now a widget that will reload
a js template, mainly depending of the current page id.
The js form initialize or update this widget giving this new page id.
On breadcrumb item click, the widget triggers a onclick caught by the form
that calls the submit with the given target.
This commit handles page transition for the breadcrumb. When going forward or
backward (next or previous page), the breadcrumb activates, deactivates and
links elements are reinitialized depending of the target page.
LINKS
Task ID: 2152223
PR #41453
Co-authored-by: Aurélien Warnon <awa@odoo.com>
The matrix data structure awaited by the server is the following :
{
question_id: {
'row_id_1': ['col_id1', ..., 'col_idn'],
'row_id_n': ['col_id1', ..., 'col_idn'],
'comment': 'This is a comment',
}
}
Before this commit, the comment was encapsulated into a dict, into an array,
with an incorrect key :
-> 'questionId_comment': [{'comment': 'This is a comment'}]
This was leading to 2 errors :
- A traceback when nothing is selected in the matrix options
- Comment is never saved.
After this commit, the comment is correctly given to and extracted by the
server. So the comment is saved and the traceback is avoided.
Task ID: 2152223
closesodoo/odoo#43086
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
PURPOSE
Allow some questions to be linked to customer data. We would like to have an
email field filled with user info / updating user info automatically in the survey.
SPECIFICATION
For now, we only want to be able to collect the user email address for a specific
question of the survey. For that purpose, add a ``save_as_email`` field on the
question model.
If this option is checked, the answer to that specific question will override the
"email" stored on the survey.user_input allowing live udpate of user input
based on given information. If multiple questions are marked as such, the
last (not empty) answer will prevail.
If user input already has an email (invitation-based surveys for example)
prefill the answer with the email so that people don't have to retype it.
GOING FURTHER (aka, incoming)
With live mode: maybe some additional fields will need to be saved
nickname
avatar
LINKS
Task 1919290
PR #41429
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: Thibault Delavallée <tde@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
Purpose of this commit is to globally rewrite the way statistics are
pre computed and used in results page of surveys. Indeed current code is
very complex, having a lot of calls to the same methods while taking only
part of its results. It also have a mix of model and controller methods,
data is computed several times a bit differently, ...
In this commit we rewrite that part. Including
* a simpler code flow;
* a simpler data structure;
* use a better naming for methods instead of "prepare_results" called
randomly within the code and re-using part of its returned content;
* use record sets / records instead of giving sub-elements of a record
like question.title, label.value, ...
Data structure
* simply give a question_and_page_ids to the template that will iterate
on pages / questions;
* have a graph_data, table_data dictionaries available for graph and
table display with simple entries;
* graph_data: holding all necessary but minimalist data for graph display
if question allows it;
* table_data: holding all necessary but minimalist data for table / summary
display;
* hold record sets of done / failed answers and answer lines;
In this commit we also simplify and clean pagination in survey graph results
* remove page_range helper tool that can be inlined in the templates
directly, doing a simple range;
* fix and improve pagination code;
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 survey.user_input.line, clean code about constraints. Purpose is to make
it easier to read and understand.
Code creating user input lines is moved from survey.user_input.line model to
survey.user_input. Indeed it is now based on a user_input record, and create
answer line related to a question, based on values coming from controllers
(and therefore frontend). It makes more sense to delegate that code to the
user_input model itself that creates its lines. Code is also rewritten to
be cleaner and easier to read.
Code computing statistics on user input records is moved from survey model
to user_input model, where it belongs. Missing translation marks are added
because translations matter.
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
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
``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
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
A new naming for ``survey.question.answer`` has been recently introduced:
``suggested_answer_ids`` and ``matrix_row_ids``. In this commit we propagate
that naming to survey.user_input.line model. New naming is
* ``suggested_answer_id``: one chosen value for single / multiple choice.
It is also used for matrix columns as those indicates the value to give
on a given row;
* ``matrix_row_id``: the related row of the suggested answer for matrix
questions;
It adds two benefits
* it finishes by _id which is always a good idea for m2o fields;
* it better indicates the use;
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
Main user answer model is ``survey.user_input``. It holds lines related to
answers given to specific questions. In this commit we rename this model from
``survey.user_input_line`` to ``survey.user_input.line`` to be coherent with
general odoo naming guidelines.
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
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 FIELD ON SURVEY.SURVEY
On survey.survey, remove question field, unnecessary related on title.
Question model holds two fields for its title: ``title`` and ``question``.
Question is simply a related on title, making the two fields completely
redundant. It is mainly due to historical reasons, when updating models for
certifications and eLearning. In this commit we keep only title field and
remove the question related field as it adds unnecessary complexity to the
model.
SPECIFICATIONS: INPUT_TYPE FIELD ON SURVEY.USER_INPUT
On survey.user_input, remove input_type and its garbage collect.
``input_type`` field exists on user input model to tell whether answer has
been created through invite or through manual click on a survey page. It
has been added a long time ago when surveys were either open to everyone,
either closed and on invite only.
Since eLearning and certification surveys access mode on surveys has evolved.
Notably being able to distinguish invite from manual survey user input is not
necessary anymore. Indeed what is important is the way people can reach the
survey, not how they created their user input.
Invitation creates token and this can be used if people effectively want to
find invitation-related user inputs.
Since 09ea5c7d49 manual entries still in draft are garbage collected.
Reason is still unclear as it is not obvious that tons of unnecessary entries
will be created. As this seems like unnecessary optimization this commit
removes that feature along with the input_type field.
SPECIFICATIONS: REPLACE URLS FIELDS BY METHODS ON SURVEY.{SURVEY, USER_INPUT}
On survey.{survey, user_input}, remove url fields replaced by methods
In this commit we remove some remaining of URL fields that are better found
using methods. Both survey and user input holds a "start" url field that is
replaced by a method call ``get_start_url`` on both survey (generic) and
user input (token specific) models. We also introduced a ``get_print_url``
method doing the same for the printable version of survey / user input.
SPECIFICATIONS: REMOVE CATEGORY FIELD ON SURVEY.SURVEY
On survey.survey, remove unused category field.
Survey model holds a ``category`` field whose purpose is to be able to somehow
categorize surveys according to their use. However using this field is not
easy as it is hidden and is a simple selection field. Module should add their
own key. Its sole use is in ``hr_recruitment_survey`` which is a niche module.
Let us clean models and lessen model complexity.
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
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
Remove dead code :
* old code bits not used anymore since several code cleanings have
already been performed;
* use tools when possible instead of manually checking stuff like
email validation;
* clean unused imports;
No functional changes should occur with this commit. It contains only
code move, not any change at all.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
PURPOSE
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
Code move main points
* move fields to have them grouped by main use;
* move methods to have them grouped by main purpose;
* reorganize some line breaks to ease reading files;
Globally this code move is done according to our famous guidelines.
No functional changes should occur with this commit. It contains only
code move, not any change at all.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
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 a user tests the Survey, he should not get a valid certification document when he succeeds.
To avoid that, we add a "specimen" watermark on the background when the user_input is a test_entry.
In addition, we also don't send the mail containing the certification for test entries.
Task#2058598
Before:
The method _get_mark called Model.exists() just after calling
Model.browse
This process makes 2 calls to database to do almost the same thing
Now:
Removed the method _get_mark and directly call Model.browse
FP feedback
Task 2066646
PURPOSE
Perform a back2basics review of survey to improve daily use, new user
onboarding and labelling.
SPECIFICATIONS
Order answer lines following question order.
Display section in answer lines form view to better understand question and
answer organization.
Add a correct flag on answer lines and display it in user input embedded
view in order to know which line are correct.
LINKS
Task 2039068
PR #36229
PURPOSE
Perform a back2basics review of survey to improve daily use, new user
onboarding and labelling.
SPECIFICATIONS
Reorder some code to better understand module organization.
LINKS
Task 2039068
PR #36229
PURPOSE
Perform a back2basics review of survey to improve daily use, new user
onboarding and labelling.
SPECIFICATIONS
Improve labels of fields and wording in actions. See commit content for proper
specifications.
LINKS
Task 2039068
PR #36229
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
PURPOSE
eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.
SPECIFICATIONS
Add menu entry inside Courses
* Certifications: kanban view of surveys of type certificate
Add menu entry inside Reporting
* Certifications: list view on surveys of type certificate
Columns: Title, Survey Stage, Registered People, Certified People, Attempts
Success Rate (certified/attempts), Average Results
LINKS
Task 1978729
PR #35061
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
To avoid having to wait the cron that distribute badges to elligible users,
we run the cron manually at the survey passed
if the survey is a certification and if the certification delivers a badge.
Task ID : 1935136
PR #31486
Purpose
=======
This commit adds the attempt number on the answer (= survey.user_input)
form & tree views.
The attempt number is always relative to its "pool" of attempts and
depends on the "invite_token" if specified.
ex: Attempt n° 2 / 4 (where "4" is the attempts_limit of the related survey).
closesodoo/odoo#31771
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As other modules than survey (namely hr_skills) now need a hook to add specific
behavior when a survey answer is marked as 'done', we removed the '_send_certification'
method and replaced it with a '_mark_done' method.
It will make it easier to override this method as it has a more generic meaning.
closesodoo/odoo#32880
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The quizz_passed field is now more important because it determines whether
a certification has been successfully taken or not.
This commit adds the quizz_passed field in:
- The search view of user_input
- The list view of user_input
- The form view of user_input (along with the score)
Task #1940360
Subtask of #1902304
Purpose
=======
Adds certification capabilities to the website_slides module.
Channel/courses can now include certifications as a new type of slide.
This new type of slide is available as a "Certification" button on the slide creation
frontend view (next to "Video", "Presentation", ...).
Users have to link the slide to an actual survey that has the 'certificate' field
set to true (that will populate the slide's survey_id field).
Slides of type certification are handled in frontend in a very simple way for now:
- A button "Begin certification" that redirects the user to the related survey frontend.
- A button "Download certification" when the user has succeeded the certification.
- When the survey is done, if it's linked to a slide, a button "Go back to course" allows
the user to go back to the slide frontend.
(There is a special use case for when the website_publisher designing the survey lands on a
certification slide: he is allowed to test the survey with a survey_input created as test_entry)
Survey creation as well as limited time, limited number of attempts, ... are still completely
handled in the survey module. That means that the user will have to first create a suitable survey
that is a certification and only then create a slide of type "certification" and link
the created survey to it.
Ideally, the taking of the survey should be transparently included in the slide frontend but
it requires a full refactoring of the way surveys are submitted. This will most likely come in
a later commit.
This commit is an advanced merge of full eLearning module (see task #1902304).
Task #1902306
Purpose
=======
When you invite people to take a certification multiple times, the user will have his "attempts" count reset
with every invitation.
This is important when there is a limited number of attempts available.
ex: A user invited twice will have 2 x allowed_attempts_count to succeed the survey.
Attempts are now separated in different pools using a "invite_token" field on the survey.user_input.
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.
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.
Task #1902306
Purpose
=======
survey.question is now also the model used for the survey's pages (with the "is_page" field set to True).
This allows to put all the pages and questions together in a o2m field on the view side and
easily reorganize your survey by dragging the items around.
It also removes one level of encoding by directly having 'Add a page' and 'Add a question'
links on the tree view of questions, enabling a faster encoding.
However, this has the downside of making the code reading a little bit more complicated.
Efforts were made at the model level to create computed fields so that the use of these models
still seems somewhat logical. That means:
- A survey still has "page_ids" (question_and_page_ids filtered on is_page = True)
- These "page_ids" still have question_ids (questions located between this page and the next)
- These "question_ids" still have a "page_id"
That makes the use and display of these information at view and controller levels easier to understand.
A field exists to differentiate answers done manually through frontend of
survey and answers created through invitation. The field was not correctly
set by the invite wizard. This commit fixes it.
This commit is linked to task ID 1935176 and PR #30689.
Purpose of this commit is to use an access token to access survey instead
of their ID. Routes are updated to use that token instead of the survey ID.
Purpose is to have less discoverable routes and be able to control a bit more
survey access even if it is not really a security parameter.
Some renaming is performed to avoid confusion in terms. Survey token and
answer token are now clearly labeled differently in the code to know which
model we are working on.
Some templates are updated to directly use the answer as base record to
have access to token and test_entry fields instead of giving those parameter
values directly in the controller. It makes some more diff but also allow
easier edition and improvement in templates when having directly survey
and answer record available.
This commit is linked to task ID 1932508 and PR #30508.
Martin Trigaux