Move data creation of survey tests from setUp to setupClass as there is no reason
to completely re-create data in between every test and this increases the test
speed without drawbacks.
Task-2199207
Part-of: odoo/odoo#79119
Purpose
=======
Improve the results page filter to allow the filtering
on questions of type text_box, char_box, numerical_box,
date and datetime.
Specifications
==============
Updating the URL filters representation to avoid passing the
question types directly in the URL parameters.
Answer matching per question type:
- char_box, text_box: 'ilike'
- numerical_box, date, datetime: '='
Adding a new filter restricts the current filter results.
Handling the filters depending on the 2 different answer models:
'survey.question.answer': matrix, simple_choice, multiple_choice
'survey.user_input.line': char_box, text_box, numerical_box, date,
datetime.
The filters can be combined but their query count doesn't add up
if their related answers data are stored in the same model.
Task-3138245
closesodoo/odoo#110252
Related: odoo/enterprise#36383
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
Globally improve the main survey.user_input form view to make it more user
friendly.
This includes fields move, new computed fields, a ribbon, ...
SPECIFICATIONS
- Make the Survey User Input model support mail.thread and mail.activity.mixin
This lets us display the chatter on the form view and allows users to
schedule activities.
e.g: discuss a participation among colleagues, add activities to check some
participation because you think the person has cheated, ...
- Add a ribbon on the form view that says "passed" or "failed" according to the
user result
- Introduce a new "Answer" column for the questions list view that is a
modified 'display_name' that displays the answer based on the question type ;
This allows to see the answers at a quick glance without having to drill down
every question to look at the "value_char_box", "value_datetime", ...
- Add the attempts count information in a stat-button, when clicked, the user
is redirected to the list view of all survey attempts of that specific user
for that specific survey
- Re-organize and move some fields
- Hide some advanced information into debug mode
Task-2729604
closesodoo/odoo#83781
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, if the survey participant does not answer questions of type:
- simple_choice
- multiple_choice
- matrix
The system does not register any survey.user_input_line with the "skipped"
attribute set to True. Meaning that this question's answer will not appear in
the survey statistics as skipped (in fact it will not appear at all).
This commit makes sure we correctly save a user_input_line set as skipped=True
when not answering to those types of questions.
A unit test has been added to make sure that we consider every non-answered
question type as properly skipped within the survey statistics.
Task-2622869
X-original-commit: 87ea302044ff7ac26888000101254b1af2524046
Part-of: odoo/odoo#76606
Steps:
- Go to Surveys
- Create an new survey:
- Questions:
1. First section
2. First question:
- Multiple choice: only one answer
- Answers:
1. First answer
- Choice: Yes
- Is a correct answer: Checked
- Score for this choice: 1
2. Second answer
- Choice: No
3. Second question:
- Multiple choice: only one answer
- Answers:
1. First answer
- Choice: Yes
- Is a correct answer: Checked
- Score for this choice: 1
2. Second answer
- Choice: No
- Options tab:
- Conditional display: Checked
- Triggering question: (First question)
- Triggering answer: (First question, First answer)
- Options tab:
- Layout: One page per section
- Scoring: Scoring with answers at the end
- Click Test
- Select the two correct answers
- Submit
Bug:
The score is 50% instead of 100%.
Explanation:
Since multiple questions are submitted at the same time, we cannot know
before saving the question whether the following is still going to be
active.
This commit re-evaluates, for each question, which are the ones that are
still active.
opw:2537713
closesodoo/odoo#72126
X-original-commit: ec836acdc7bf10212f14a8bc98eac4cfa2f12e26
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
The goal of the draft state on survey is to have the survey under edition
mode before before sending it to participants. Under this mode:
- the responsible can test it (can be done with "In Progress" mode)
- the survey can't be answered (same as the state closed)
The risk that the survey can be leaked before being ready is really
limited. If it's a live survey, participants will have to guess the
4 digits access code and wait for the host to go to the next question.
Else, participant will have to guess the token.
Considering these facts, the use of the draft state is very limited so
'draft' state can be dropped. If we do so, we are left with only two
stages that are 'open' and 'closed'. But whether to consider survey
open or closed can be simply achieved with active field we already
have (if active=False, survey is closed, otherwise it's considered
as open).
So with this commit, we remove the state field from survey and thus
simplify the flow. It means that we no longer require 'Start Survey'
button, and so that button is also removed, and for the closed surveys,
instead of the button 'Set to draft', now we have a 'Reopen' button
which will activate the survey. And instead of displaying few buttons
after saving a record, we now display all the buttons from beginning.
Task ID-2389434
COM PR odoo/odoo#62712
ENT PR odoo/enterprise#15217
UPG PR odoo/upgrade#2006
Our CSRF tokens are based on the current user session, and automatically
expire as soon as the session does.
However, they also come with a default 1h expiration delay. This proves
to be a frequent annoyance for users who pause more than 1h on a form
before submitting it (e.g. user logs out and browser sits on login page
until the next day).
It can even lead to blocking bugs, e.g. when the 1h expiration occurs in the
middle of taking a survey exam, and the user is never able to post the
answers that are only present in the state of the form they need to
post.
More generally, users have a hard time understanding those CSRF expiration
errors, and don't know how to react.
Longer default expiration times have been considered (e.g. 1 day or
1 week) but those would not bring any identified benefit in terms of
security, while still giving a chance that some users would experience
the incomprehensible HTTP 400 errors).
Attacks that can typically compromise the CSRF token (XSS, RCE)
can achieve as much, or more, on the system or user account than what is
possible with the token. And nothing generally prevents the attacker
from using the token immediately after capturing it, during the initial
attack, making the expiration delay rather irrelevant.
Given there seems to be no significant benefit in expiring the tokens
before the session itself, let's just keep them valid as long as the
session.
Note: sessions are GC'd automatically after 7 days of inactivity,
which gives an effective 1 week expiry for abandoned web forms anyway,
as the token expires with the session.
Additionally, fix `survey` module tests, that were using an incorrect
regex for extracting CSRF tokens.
closesodoo/odoo#51499
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
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;
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
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>
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
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
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
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
Purpose of this commit is
- to make the survey js controller a widget, to be more 'odoo-standard'.
- to lessen number of RPCs and clean old code for prefilling and validation of
surveys.
Clean Prefill :
Prefill can be done directly in the template as the template has already
all the needed values (in answer object).
Clean Validation :
Validation is done at server side and is independant from prefilling values.
Dates:
Dates are now formatted directly in the template, at rendering, using a
format_date fonction pointer called in the template.
Don't use widget in review mode:
Remove o_survey_form class from review template as only dates were processed in
the widget for review template.
Breadcrumb :
Remove button previous, prev=prev and go_back mechanism :
The previous page is handled by the breadcrump
Remove redirect url mechanism.
Breadcrumb now saves the answers when going to a previous page.
Move o_survey_form class to a higher div to englobe breadcrumb in the widget
and ease his handling.
Remove locale load as already done in session.js#load_modules
This commit modifies the route type of survey submit to work in json.
The js survey form controller calls now manually the route via rpc.
Task ID : 1930132
PR #32419
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@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
=======
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.
Purpose of this merge is to improve access mode and authentication management
introduced at 9771fdfe8f . Purpose of this cleaning is to simplify options and make
them clearer. Instead of a selection with 4 entries we propose to use two
fields on survey model :
* access_mode: everyone with a public link can access and answer; or only
invited people;
* login required: whether people have to login to answer or not;
All main use cases are covered with combination of those two options.
This commit is linked to task ID 1932508 and PR #30508.
In this commit we extend access option on survey model. Access mode is now
defined as
* public: everyone can access this survey. People having a link to the survey
can create answers and fill survey. Those are used for example as
satisfaction surveys;
* login required: only users can access this survey. Depending on auth
signup configuration this either limits survey access or forces people
to create an account;
* employees only: only users belonging to base.group_user can access this
survey. Those are used for example for internal polls;
* on invitation only: only people receiving a token can access this survey.
They do not need to be an user, having a token is sufficient. Those are
used for example for appraisals;
Note that survey officers and managers can always create and update answers
according to their ACLs.
In this commit we also improve a bit survey form view while changing the
access field. Surveys users now have access to all buttons and some labels
have been updated to better fit current Odoo style. Archive button is now
always displayed as it is considered as a standard way of managing surveys.
This commit is linked to task ID 1911586 and PR #28986.
Purpose of this commit is to add some prepared data in survey common test
file. We also add some tool methods in order to easily create new questions,
answers and answer lines. Some specific assert methods are also added to
avoid noise in tests and avoid having to duplicate some check and assertions.
This commit is linked to task ID 1911238 and PR #28831.
Purpose of this commit is to clean a bit survey test files before updating
them and creating new tests. In this commit we add a common file holding
user creation and we use the recently-introduced tool method to create
test users. Survey test class is done child of SavepointCase to use
breakpoints and avoid recreating data at each test.
Future commits will gradually remove unnecessary content for test_survey.py,
rewrite part of it to be easier to understand and add new tests.
This commit is linked to task ID 1911238 and PR #28831.
Nikunj Ladava