PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
Purpose
=======
This is the first huge step to improve the test suite in several ways:
- Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases.
- Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing.
- Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners.
- This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example.
closesodoo/odoo#39868
Taskid: 2075739
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds a SQL constraint to force the min_karma of the gamification.karma.rank model to be
above 0.
A karma_min set to 0 (or lower) could create some frontend issues when displaying required karma.
PR #39870
Task#2032649
Purpose is to have all karma related tests in the same file to ease finding
them back. Some tweaking is also done like using a savepoint case and ensuring
tests can always be re-run.
LINKS
Task ID 2003505
PR #34594
PURPOSE
Allow karma gain tracking enabling notably display of top users based on
weekly / monthly gain in website profile.
SPECIFCIATIONS
Each time a user gains karma a record is created in the gamification karma
tracking model. Scheduled activity runs to consolidate the records into
monthly gain records to avoid having crowdy table and unnecessary noise
in karma gain.
This model is made private and only accessible through some dedicated
compute methods / controllers used in website profile.
In website profile module buttons are added to see users ranking based
on their total karma (like before) but also by last week and last month
gains (using the newly introduced tracking model).
LINKS
Task ID 2003505
PR #34594
This commits avoid to call recompute when you write on the rank without
touch the karma_min value.
On write on karma_min, we have 2 cases:
- Rank order are the same, just need to recompute the rank for the user
that could be impacted. Eg. if karma_min changes from 45 to 50, we need
to recheck for all user between 45 and 50 their new rank.
- Rank order are not the same, we need to recompute for all users.
(could be still improved if needed)
When you recompute the rank on a list of users, depending of the number of
users (bulk if more than 3 * number of rank) we check for each user what is
the new rank, or for each rank whats is the new users.
task-internal
No way to edit a rank on the prod server. Lock sql -> crash server
closesodoo/odoo#34835
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since 960360a, when computing badge stats, a datetime was compared to a
string leading to a traceback. e.g. when clicking in employess >
badges.
Also, due to a typo, the compute method was assigning the stats result
to the wrong attributes. e.g. 'stats_my_this_month' instead of
'stat_my_this_month'.
With this commit, the above mentioned issues are fixed and a test is
covering these issues to avoid regression.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Raphael Collet