| Age | Commit message (Collapse) | Author |
|---|
|
- use real join
- skip useless join on res_users and gamification_challenge
- skip null end_date criteria to compute less reached goal
closes odoo/odoo#69668
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Trying to improve the resources used by the challenge update cron
operation.
Before this commit some count-based goals and all sum-based goals were
computed with one select count or sum per user.
After this commit each count or sum based goal is computed in a single select
for all users. The goal form now also allows to enable batch mode for
sum computations. Other changes include:
- adding an index on the challenge_id of goals after verifying the
positive impact of such an index on high volumes on a staging server
- introducing additional intermediary commits to allow massive crons to
catch up over several attempts.
task-internal
closes odoo/odoo#63030
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
There is no field 'ids' on a gamification.goal, but one called 'id'
Without this commit, calling _get_serialized_challenge_lines (or
indirectly, calling report_progress) with a non-empty subset_goals was
failing due to an invalid domain.
This is not supposed to happen on standard flow but can be triggered
with manual modification of date fields and refreshing a challenge.
Fixes odoo/odoo#25913
closes odoo/odoo#54387
X-original-commit: 1e3483d2fc99763940396936758cf99b14d0a118
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
It has always been a best effort until the v13 to have false as default value
for boolean field.
Until v13: https://github.com/odoo/odoo/blob/12.0/odoo/models.py#L3645
During ORM refactoring in v13 it has been replaced by a default value in sql
From v13: https://github.com/odoo/odoo/blob/13.0/odoo/tools/sql.py#L79
But with a typo since columntype for boolean is bool and not boolean.
What's mean that in v13 we have a lot of null value for boolean (~=False)
In all cases, we try to be aware and check Falsy boolean with 'null or False'
(https://github.com/odoo/odoo/blob/13.0/odoo/osv/expression.py#L1230)
So we should do the same when we write pure sql in method bypassing the ORM.
closes odoo/odoo#53391
closes odoo/odoo#54458
Related: odoo/enterprise#11319
Related: odoo/enterprise#11838
X-original-commit: 118c9f6aafd423f415b2bbfcf8a9cfcd676d9b92
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
|
|
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
|
|
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
|
|
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closes odoo/odoo#45716
closes odoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closes odoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
|
|
computation
We are initializing over the limit to make sure we will compute it at least once.
If the target goal is set to 0, we are facing a division by zero error when
displaying the gamification goal just after initialization.
closes odoo/odoo#40735
X-original-commit: 24546e7c4cac61efea8d3f9e558518a55ef9acd2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
challenge.challenge_category
To ease grep in the code, especially that challenge is quite heavily used.
Task ID : 1961053
PR #32594
|
|
closes odoo/odoo#36721
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
closes odoo/odoo#36491
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
If a goal definition with a target goal of 0 and "higher the better",
instead of dividing by 0, set a progress of 0% (it is not possible to
compute the progress)
Task id: 2057898
|
|
If a manual goal has a target of 10, it should not start at 9 but 0
If it has a target of 0, it should start at -1
Task id: 2057898
|
|
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
|
|
Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)
Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).
Small performance improvement
* browse recipients instead of search in _notify_email_recipients;
* todo in future optimizations: mayybe be improve by searching on ids
and is_blacklist immediately;
Related to task 1943901
Linked to PR #32404
|
|
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
|
|
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'`
|
|
|
|
|
|
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 #28773
closes odoo/odoo#29836
|
|
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%
closes odoo/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
|
|
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).
|
|
|
|
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.
|
|
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 0c649644db0 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
|
|
|
|
Includes compatibility-change to website_forum: a selection(callable)
converted to a Selection(list) since that can easily be extended in the
new API.
|
|
|
|
Also include 2939800ed438505be9c919d4edca0ce624e6bf8e which seems to
have been forgotten during previous forward-ports
|
|
|
|
Before this patch, the challenges with an end date in the future were closed at
the first cron run.
opw-669995
|
|
|
|
When evaluated, the translation function never finds a match if a variable is
integrated into the untranslated text.
SHAME! :bell: :raising_hand:
|
|
|
|
|
|
update is a method from the ORM with a different signature.
Avoid name clash. Issue 646610
|
|
Courtesy of Kris Krnacs
|
|
Writing frequently to master data, and particularly to res.users
records is dangerous because it can temporarily delay/abort
concurrent transactions due to FK locking/serializability
heuristics. (Even with PostgreSQL 9.3+)
The `login_date` field updated when a user is authentiocated
is still useful but better handled in a separate table that
exclusively receives independent INSERTs (no UPDATE/DELETE).
This minimizes the chances of transactional conflicts.
This commit moves the login_date info into a separate
`res.users.log` table for this purpose, replacing it
with a related field. The user and login date info are
automatically handled by the magical fields (create_uid,
create_date) in `res.users.log`.
The related field must not be stored because that would
create the same problems as the original field.
In order to cleanup redundant entries in res.users.log
the 'auto-vacuum' cron job used for TransientModels was
extended to be a generic "internal data vacuum cleaner",
and now takes care of this as well.
The code for updating last login and vacuuming was split
up into smaller methods to make extensions easier.
Fixes #8585
Fixes #8590
|
|
|
