Purpose of this commit is to clean motivational capabilities of gamification
ranks[1]. It makes more sense to store a motivational to achieve on next rank
itself. We therefore rename the field and provide nice demo data that will be
used in elearning use of gamification ranks.
Commit linked to task ID 1941250 and PR #31133.
[1] task ID 1922159 (landed at 91ee6ba5a7)
- add menu to configure ranks in gamification tools because was missing
- move admin karma data in gamification : karma linked to gamification
and not forum anymore
- fix rank computation : next_rank_id could never been recomputed correctly
if rank are created in a karma ascending order.
Task ID : 1922159
PR #30988
To encourage forum and slides users to be more active ranks are now added.
They are directly linked to karma. The more the user has karma the more his
rank will be high.
The default rank is Newbie, with 1 point of karma. Users with 0 karma are
considered as inactive on forum or slides. When a user reach a new rank
a mail is sent to him to congratulate him with his new rank.
To add a button in the mail template to allow users to go directly on
a website section (like forum or slides) simply override
get_gamification_redirection_data to add the target url.
Partial commit linked to eLearning project. Main specifications related
to gamification and user profile can be found on task 1922159 (PR #30514).
Main specifications related to eLearning can be found on task 1902304
(PR #29876).
Purpose of this commit is to prepare addition of gamification in slides /
eLearning platform. In order to be able to use karma and the badges in other
modules we move those models in gamification.
Partial commit linked to eLearning project. Main specifications related
to gamification and user profile can be found on task 1922159 (PR #30514).
Main specifications related to eLearning can be found on task 1902304
(PR #29876).
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
The generated query in _generate_goals_from_challenge lacked spaces
between the date clause, which caused a traceback.
The traceback only appears since v12 and above, because the dates are
now casted as dates (::date) in SQL, which has to be followed by a
space. Before that it was "fine" as SQL does allow you to write
g.start_date = '10-10-2017'and g.end_date = '11-11-2017'
Closes#28773closesodoo/odoo#29836
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
A challenge with less than 3 participants was failing with a key error
The challenge line has only one 'goal' result per participant
As the template is set in a noupdate, even a module update does not fix the bug
Generate fake goals that will be displayed in the top 3, e.g.:
1 Bob $100 42%
2 Alice $50 21%
3 0 0%
closesodoo/odoo#28363
Purpose
=======
Remove the method 'render_template' in mail.compose.message as the indirection
is not useful. Call the method on the correct model (mail.template) directly.
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
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.
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Try to remove cr.commit (and rollback) from module and db install:
* put a savepoint around test data loading
* remove a bunch of commits sprinkled throughout
* remove rollback on data loading failure (assuming it bubbles up, the
entire module's installation should be rolled back)
* add commit right before the tests are run, so they can run isolated
and still see whatever was done when installing their module
* convert a few explicit closing to context managers
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
Purpose of this commit is to enhance quality of templates proposed by Odoo
and make them use notification layout when send by emails. Those emails
are cleaner and more up to date compared to other emails.
Including
* calls to message_post now use the light notification layout. It is
given as parameter to the message_post process;
* some cleaning in templates;
This commit is related to task ID 51122 (and PR #24052).
update_goals is called through the 'Run Goal Challenge Checker'
cron, potentially on a large amount of goals.
With self containing ~400k records a worker has been observed to use
~3.4 GiB. With sensible memory limits this will probably cause the
worker to be killed.
To avoid this turn of prefetching in this initial loop. Performance
shouldn't be affected too much because in the following loop
prefetching for goals will still take place per definition.
opw-1840666
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
In the curent behaviour, the users of the challenge are ordered
regardless of the goal definition (higher wins or lower wins).
This impacts the report email with the podium of users and always puts higher on top.
This fix changes the ordering depending on the goal definition type.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
The field user_domain allow to get the list of users for which a
challenge is applied. The javascript framework for a char_domain widget
sends a JSON list to the server, but the server saved it as a string in
a Char field.
Hence we can have a list (in values received by write or create) or a
string (when getting the field value of a record).
Since 0c649644db this caused an error when user_domain was not empty.
This commit solves it by having _get_challenger_users always receiving a
string.
opw-708177
Give some details about the badge: its description, its image, who granted
it, ... Otherwise it is quite complicated to understand the email content.
Thanks to @mart-e who reviewed and tested.
If render_template get list and not id, a dict is returned.
Force the param to be a int, allow to don't use the multimode from render_template.
Avoid to get message like:
<p>{1: u'\n </p><p>Congratulation, you have received the badge <strong>Autobiographer</strong> !\n </p>\n\n'}
<p>{2: u'\n </p><p>Congratulation, you have received the badge <strong>Autobiographer</strong> !\n </p>\n\n'}
<p>{3: u'\n </p><p>Congratulation, you have received the badge <strong>Student</strong> !\n </p>\n\n'}
<p>{4: u'\n </p><p>Congratulation, you have received the badge <strong>Supporter</strong> !\n </p>\n\n'}
Thibault Delavallée