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>
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
Add a new demo survey about a quiz: a survey with scoring but no certificate.
Have almost all possible combinations of questions and options (notably choices
to have a scoring) and answer lines in order to be able to, notably, debug
the statistics / result page.
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: 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 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
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>
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
=======
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 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.
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 provide a new simpler survey as demo data in
survey application. Current survey is about Odoo use which is not coherent
with the demo data set used currently in Odoo. It is now a survey about
ecommerce use with an example of each different questions.
Survey tour is updated accordingly. It now uses a standard routing instead
of the test route. Indeed purpose of tests is to use real life use case
not corner case like testing capabilities of survey application.
This commit is linked to task ID 1912228 and PR #29303.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Martin Trigaux