When the user opens the survey module for the first time, the user may
find it difficult to create and configure a new survey as there are many
options available. To improve the onboarding experience of the user, we
will provide a new link on the action helper of the survey module (for
the kanban and the list view of the surveys).
When the user clicks on that link, the system will open a new modal. The
user will then be able to choose a sample to load. Each sample will be
pre-configured for specific purposes. We will have:
- A sample for the feedback forms
- A sample for the live presentations
- A sample for the certifications
After loading a sample, the user will be able to adapt it to fit their
needs. Thanks to the samples, the user can create a survey more easily
and more quickly.
task-2670605
closesodoo/odoo#79255
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Co-authored-by: Carlos Valverde <cvs@odoo.com>
Average duration of each survey is added. To avoid performance issues value
is not stored, and calculated with raw SQL. It requires to have an end
datetime on survey user inputs, allowing to compute average duration it
took people to complete survey.
Live surveys now open in a new tab instead of in-place.
Also rename some css / scss files to ease understanding. Remove unnecessary
class on survey form view.
Task-2634805
PR odoo#72298
Part-of: odoo/odoo#72298
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Mariska Archielli <ram@odoo.com>
Co-authored-by: Thibault Delavallee <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: 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
Adds two stats button on res.partner form view :
- The first one will show all the courses that the partner is following.
- The second one will show all the certifications the partner has passed.
When the partner is a company :
- All the courses followed by all the partners are shown without duplicate.
- All the certifications passed by all the partners are shown.
PR : #34908
Task ID : 2034097
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit allow gaining a badge at the end of a certification survey if succeeded.
The badge can be configured on the survey if the certification mode is activated.
The badge is linked directly to the survey and not the challenge,
because it makes more sense to configure directly the reward on the survey and
not the way to gain this reward. As the way is always the same.
Only one badge can be set on the certification survey.
Only the name, description, image and badge level can be configured.
The rest of badge configuration is automatically set to correspond to the use case.
When a badge is configured on a certification survey, the needed challange, goal
and challenge line are autogenerated.
The badge is available on the user's profile page if he gained it.
Once the badge is configured on the survey, he cannot be changed
(remove + create new one), only modified (badge attributes edition).
The only way to remove the badge is to uncheck 'certification_give_badge'.
When removing the badge from the certification survey, all the autogenerated
records (at badge creation) are deleted to avoid ghost records (as they have
no purpose outside of this context). If the badge is owned by someone, the badge
is only archived. If nobody owns the badge, the badge is deleted.
Survey users now have the right to create badges but not challenges or goals.
All the autogenerated records are handled in sudo, to allow the survey user
to configure a badge on their survey.
Note : To avoid having to rewrite the complete context in an xpath expression
only to display the certification badge on the user's profile page,
the default website_published value of the certification badge is defined
directly in the survey module even if survey does not depend of website.
This attribute will be ignored until website module is installed.
Task ID : 1935136
Closes PR #31486
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
=======
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 polish a bit this old module before working
on it. Contains
* split python model into separate main files to ease models understanding;
* split views into separate main files to ease views finding;
* move data lost in views to data files (server action notably);
* merge templates in the same file to have all available at hand;
* move assets in their own file in order to remove noise from templates;
No functional behavior change should occur with this commit. Only move
has been performed.
This commit is linked to task ID 1903617 and PR #28166.
Purpose of this commit is to rename some files before going into some more
work. No split or cleaning is done here, only preparing by doing some pure
renaming.
No functional behavior change should occur with this commit. Only move
has been performed.
This commit is linked to task ID 1903617 and PR #28166.
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
