This fix correctly displayed motivational of next rank to achieve depending
on current karma. Indeed description_motivational field is not the
motivational to reach next rank but to reach the current rank, taken from
previous rank point of view. That way a given rank is configured by modifying
only 1 data.
When not having any karma points (newly created user) the next rank is computed
as being the first available rank. Motivational phrases and badges are updated
accordingly. This commit partially reverts 489c8623e2.
Result
* new user with no karma: next rank is the first rank;
* user with karma and next rank: as currently;
* user being at final rank: next rank is just current rank with a 100%
circle;
Linked to task 2005840
Related to PR #34220
Contains some small fixes
* correctly order leaderboard by descending karma, not creation date;
* top 3 users displayed in footer banner should be published, otherwise
displayed images do not match the top 3 displayed in the page displayed
when clicking;
* correctly say Leaderboard is an overall leaderboard, not only limited
to the current week;
Linked to task 2005840
Related to PR #34220
As user is a loop variable we can directly use its index instead of a rank
position that is not always correctly computed when not being logged due
to access rights issues.
Linked to task 2005840
Related to PR #34220
After this commit https://github.com/odoo/odoo/commit/ff870099c588e56 some of the events are left
in website_forum, that caused some buttons to be inactive. In order to fix that
events moved to website_profile.
Note: code is moved as it is. Cleaning class / namespace will be done in master
to avoid issues due to stable version.
Related to task 2006045
closesodoo/odoo#34138
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In case of failure at token creation, raise a proper UserError instead
of a generic traceback.
opw-2025723
closesodoo/odoo#34420
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Avoid crash at currency conversion when no company is set on the SO
opw-2009044
closesodoo/odoo#34408
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
It's currently possible for binary downloads to be missing an
extension entirely. Generate an extension from the mimetype and use
that. Also ensure the existing extension (if any) matches the
mimetype.
Warning: this may require adding new mimetype/extensions pairs to the
local mimetype database similar to
f413d155df.
Also fix missing or incorrect filenames on records without a filename
field: in some Odoo versions the client would send a filename of
"null", resulting in a download of e.g. "null.pdf" instead of the
attachment or inferred name.
Task 2025716
closesodoo/odoo#34299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Make a SO with a product that have a carriage return in its
description
- Export FEC report
The CSV contains new lines and is not correctly formatted.
opw-2026861
closesodoo/odoo#34385
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install stock module
- Activate multi-company and variants
- Create a second company
- Create a product with 2 variants
- Create a picking with the product for both companies
- Add an attribute on the product with 2 values
- Save
An AccessError is raised on `stock.move`.
It arises because the field `product_qty` on `stock.move` must be
recomputed but is on a record in a different company.
The `try` / `except` clause doesn't protect against the recomputation.
Indeed, what happens is:
- try to unlink in batch => AccessError due to recomputation
- try to unlink individually => AccessError due to recomputation
- try to write individually => the field couldn't be recomputed before
(flagged as dirty), so try again to recompute => AccessError
We perform the operation as sudo, and take care of checking the access
rights beforehand.
opw-2009450
closesodoo/odoo#34369
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When registering a payment against multiple vendor bills and change the memo,
the memo must be populated to all the payments. This behavior has been introduced
with the following commit in stable 11.0: c04065abd8
opw:2024652
closesodoo/odoo#34322
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Backport from 12.0 to 11.0 (commit: 3cbdfe8807)
- Have two crm teams with the same team leader, and without team members
(team1, team2 as instance).
- Create a new lead, add as Salesperson the team leader, and as Sales
team the second previously created team (team2).
- Save the new lead.
Before this commit, when we save the lead, the sales team will change,
to set the default sales team for the chosen Salesperson, in this case
team1.
opw-2005924
closesodoo/odoo#33898closesodoo/odoo#34327
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
This commit improves the elearning onboarding on the quizzes
If the user is not logged in, a log in button will show up under
the quiz
If he is logged in but not a member of the course and the course is public,
a join button will appear under the quiz
If the course needs to be bought, a buy button will appear under the quiz.
If the course is on invite only, a message under the quiz will inform the
user about it
TaskID: 2003986
PR: #33861
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, while editing user profile from frontend, biography is displayed in
textarea despite of being an HTML field.
This commit fixes the behavior by providing users with wysiwyg ediotr to
update their biography while editing profile from frondend.
task-2007731
closesodoo/odoo#34207
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, it was considered as an error because status was not OK
closesodoo/odoo#34377
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit https://github.com/odoo/odoo/commit/0c6e0d660ea00ad7ee9a3e94c0ac944cdf46565f
used flex to properly align address information and the fa icons. The
problem is that using flex prevents the parent div to ask for the
address information to be center/right aligned. This is the case for
the job pages in internal.
This commit uses display: inline-block on the top-level element of the
address to solve the problem.
opw-2000947
closesodoo/odoo#34371
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As we will move those from other localizations to base,
we add those for Mongolia to base already.
closesodoo/odoo#34281
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A special folder named `0.0.0` can contain scripts that are run on
upgrade of any version.
They are useful to make some sanity checks or other verifications to
ensure database consistency.
The first version of this patch used the more eye-catching `any` for
the migration folder, but it was problematic for upgrading from an older
version that doesn't contain this patch.
Using a version "number" containing two dots is required to avoid it
being prefixed with the server version (see `convert_version` method) and
resulting in a version like `10.0.any`.
Such version would have been executed, even without this patch, when
upgrading from an older major server version (9.0.1.0 < 10.0.any).
closesodoo/odoo#34268
Signed-off-by: Christophe Simonis <chs@odoo.com>
- Create 2 included taxes: 21 % and 6 %
- Create a product A with 21 % as default tax
- Create a fiscal position to map the tax 21 % to tax 6 %
- Allow the fiscal position in the POS
- Add product in a POS order
- Apply the fiscal position
The subtotal is not recomputed correctly. On the other hand, if the
fiscal is first set then the product added, there is no problem.
This is because the `fix_tax_included_price` is only called by
`add_product` and not when changing the fiscal position.
opw-2020755
closesodoo/odoo#34260
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).
1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).
Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.
2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.
closesodoo/odoo#34243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the No Change status wasn't properly set because
the `filehash` wasn't passed to `_binary_set_headers` and because
the status was not changed to 304 if it was already set to 200 earlier.
This commit fixes this issue and also prevents images to be processed
in `content_image` if the status is 304.
opw-2008426
closesodoo/odoo#34032
Signed-off-by: Christophe Simonis <chs@odoo.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
closesodoo/odoo#34284
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Thibault Delavallée