Purpose
=======
As an Interviewer, I want my questions to be as clear as possible. To this end
I would like to be able to detail a bit which kind of answers I expect.
Specifications
============
For all the question types that require an input, display a char field
"Placeholder" in the Answers tab with an helper that says:
"When set, this text will appear in the field to help participants answer."
Then on the survey, display the placeholder in the question input zone.
Task-2671388
closesodoo/odoo#78682
Related: odoo/upgrade#2998
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to clearly separate various available demo surveys, their user
inputs and input lines. It is easier to update and maintain those demo
data in several files than hidden in big files or CSV files. No change
should occur with this commit as this is only some data manipulation.
We also quickly cleanup some demo data in this commit. Notably
* remove unnecessary user inputs;
* improve passed / succeeded statistics by improving or adding right
answers;
* fix some typos;
Task-2634805
PR odoo/odoo#72298
This commit enable users to set a 'Responsible' for the survey by
adding 'user_id' field. Demo data for the same is also updated.
Task ID-2389434
COM PR odoo/odoo#62712
ENT PR odoo/enterprise#15217
UPG PR odoo/upgrade#2006
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
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit slightly improves the survey form by adding a few cosmetic changes,
notably:
- Add/reduce some margins/paddings
- Adjust colors/font-weight
- Adjust heights
- Change some icons by more fitting replacements
- Center matrix choices
- Move survey progression to bottom-right
- Remove ugly jumbotrons
- Hide survey title in page_per_question layout
- When there are 5 or less option for simple_choice or multiple_choice
questions, display the options vertically.
- Only show the textarea for the "comment answer" if the user clicks on the
related option.
One of the biggest design change is the introduction of a "minimized layout"
that reduces the width of some question types on bigger screen.
This gives a cleaner look to the survey form.
Impacted question types:
- Numeric
- Date
- Datetime
- Simple / Multiple choices
Technical note: As the survey progression is now outside of the survey content,
that was re-rendered on every submit, we have to manually refresh the
progression with a second template render on the controller side.
Small fix addition:
We also fix the matrix key selection feature in case the matrix had a total of
more than 25 options, which would raise an error.
Indeed, they "use key selection" condition only checked the number of rows,
and not the rows * columns (total number of options count).
LINKS
PR #46768
Task 2208574
Adding additional demo and test data for new scorable question types:
'numerical_box', 'date', and 'datetime'. Includes both a scored and
unscored (i.e. answer_score = 0) version for each question type to
ensure differing behavior is viewable in survey results.
Also updating existing data/tests to:
1. Follow American standard for $ placement.
2. Have hardcoded 'answer_is_correct' and 'answer_score' demo data (due
to updated correct answer implementation being done via frontend
input only)
3. Update minor errors in the existing demo data (for example, removing
2nd answer for a single answer choice question for the same survey
submission).
Upgrade PR: odoo/upgrade#835
Task ID: 2061937
In this commit, all the questions type have been redesigned to look more fancy.
(impacted question types : radio and checkboxes, text boxes (textarea and text
inputs, date and datetime inputs and matrix)
For radio and checkboxes, both design have been aligned to work the same way
(except checkboxes can still have more than one selected option).
Selection by key have been applied on those two question types if the number of
option is under 26 (to use all the alphabeat character for selection). This
selection by key is only available on page per question layout.
Tests have been adapted accordingly to the redesign (typically for choice and
matrix inputs)
* Progress Bar
This commit adds a progress bar to the survey to inform the user
where he is in the survey filling process.
There are two progress modes:
- Number : will display the number of the current page on the total number
of pages (or questions if layout mode is question_per_page)
- Percentage : will display the percentage of page or question already done
So this leads to, on last page:
- in Number mode :
the progress bar div is 100% filled 3 / 3 pages [===]
- in percentage mode :
the progress bar is aligned to percentage 66% completed [== ]
* Print Widget
A widget is added for survey print mode in order to resize all textarea to fit
their content, instead of showing a scroll bar. This can be usefull if user
wants to print the results. He will get the entire content of the 'textarea
answers' instead of only the two first lines.
* Misc
This commit also :
- adds background image to survey.
- redo quizz correction and add some data to illustrate non scored
questions rendering in print template
- review breadcrumb style
Note : readonly data option on survey form widget is not set anywhere yet but
the usage is done in prevention of the future work on presenter view for survey
session mode.
Task ID: '2150291'
PR #43237
This commit prepares the complete redesign of survey.
Simple choice question type will only use the radio button display mode.
So the dropdown display mode is deleted.
Task ID: 2152223
PR #41453
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: 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
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 header is quite fun. If a question is not a question it should
not have a type. Maybe it should not be a question but, hey, you don't always
do what you want. That's life my dear Lucette.
In this commit we remove required attribute from python field definition of
question_type and make it required conditional based. Real questions have a
type, unreal questions have no type.
Alss update Questions menu entry to display only real questions, not unreal
questions.
Most of this commit message makes no sense, but remember who asked to push
this model.
Task 2053833
closesodoo/odoo#35835
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Hardik K Prajapati <hap@odoo.com>
Co-authored-by: Mohammed Shekha <msh@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>
- when answer is correct, then score should be +1.
Related to Issue: 1967506
closesodoo/odoo#32612
Signed-off-by: Jérémy Kersten (jke) <jke@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.
David Beguin