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
Before this commit, if a badge is set on the survey, duplicating it always
results into a traceback due to sql constraint. Indeed due to uniqueness
constraints between survey and badge having the same badge for a duplicated
survey was leading to an error.
We had two options
* duplicate the badge itself;
* remove sql constraint and add a required on badge in view when having
a certification (aka, survey giving a badge);
First solution is somehow limited. It means updating badge name, checking
its goal, ensuring all parameters are ok. Moreover it is quite hidden when
duplicating survey. End users will maybe not see what to are doing.
We choose to remove copy flag on flag and badge. That way end users have to
manually re-check the flag, and create a new badge. We remove the hard
constraint and set a required in the view so that functionally behavior
is the same.
Task ID-2265556
PR odoo/odoo#52391
Purpose of this commit is to synchronize active status of certifications to
their badges. When archiving or activating a certification, its badge is also
archived or activated.
Task ID 2170708
Community PR odoo/odoo#46563
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
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.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
ijas ahammed