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
Since admin is responsible of all created demo channels and then re-added
manually as member in demo data of slide.channel.partner he is actually
twice member of some channels. This commit fixes that by resetting its
membership status before adding membership demo data.
PR #36756
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'`
Task #1945036
Purpose
=======
If the user fails his last attempt at a course certification, we remove him from
the members of the course (and he has to enroll again).
He receives an email in the process notifying him of his failure and suggesting
he enrolls to the course again.
The purpose is to have a 'certification flow' where the user can re-purchase the
certification when they have failed it.
This could lead to some issues if the course containing the certification also has
other slides with content because the user will not have access to them after failing.
This also prevents configuring courses with multiple certifications since the membership
will be removed at the first failure.
These use cases are considered "non standard" by the business and are thus not handled
in the code. We assume that users will configure their courses "correctly".
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).
Thibault Delavallée