Before this fix, the customize button was updated with each character,
which slowed down the fast insertion of characters and used resources
unnecessarily.
With this commit, when using autocomplete inputs in Discuss
or chat windows, the 1st item is automatically auto-focused.
Example of autocomplete inputs:
- Discuss: "Add or join a channel" in sidebar
- Chat window: when clicking on "New Message" from systray
messaging menu.
As a result, we can use keyboard keys to navigate and select
the desired item.
Task-ID 1894447
closesodoo/odoo#30207
Purpose of this commit is to introduce a new way of displaying and managing
slides in eLearning module. Its purpose is to give a better experience to
users when going through a course. Notably a fullscreen mode allows to take
lessons one by one without going out of the elearning display. Integration
of all slide types eases taking the course step by step.
Quiz are introduced in this commit. Those are an addition to slides with
some question / answers (multiple choice). It allows customer to gain karma
and improves gamification. Certifications are still done using the survey
application. Quiz targets only small tests at the end of a given slide.
A new widget is added to display and control slide display in fullscreen
mode. Old display is still available for documentation channels or when
going out of fullscreen mode, to see details on comments / review / statistics
and have access to share options.
This commit is linked to task ID 1902304 and PR #29876. It closes the main
work on refactoring website slides into eLearning, with other tasks already
merged in current community [1][2][3][4][5].
[1] Task ID 1940360 landed at b2149bc7a2: certification inclusion
[2] Task ID 1936153 landed at 6c6179e57c: homepage inclusion
[3] Task ID 1937160 landed at 8b7605c9e5: selling courses
[4] Task ID 1922159 and 1940516 landed at 5fa651cb01 and 6a64c3ce82:
new user profile and gamification of slides / forum
[5] Task ID 1938643 landed at 77b5673a0d: upload channel/slide
Purpose
=======
If the activities are available on a model (i.e. inherits mail.activity.mixin),
add a progress bar based on the activities if nothing is defined yet.
closesodoo/odoo#24777
1) Remove the total record tooltip from kanban group.
2) Remove progressbar help from kanban view.
3) Improvements in testcase since we have removed total record tooltip.
The image handle (grey overlay over the image) was not properly
repositioning on scroll in the product configurator (a side effect of
not having a popover).
closesodoo/odoo#31226
Depending on the scale, the number of units to add to today to
compute the default period. Examples: An offset of +1 in default_scale
week will open the gantt view for next week, and an offset of -2 in
default_scale month will open the gantt view of 2 months ago.
The web editor inserts zero-width characters (unicode 200B) around media
when inserting them in the DOM so as to be able to edit before and after
said media (contenteditable caveat). It should however not do so in fake
not-editable nodes - such as the navbar - given that we do not expect to
edit in them but only to replace the media. This ensures that behaviour.
closesodoo/odoo#31200
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
Purpose
=======
The "publish/unpublish" widget is always shown on slide.channel/slide.slide for
a website_publisher user even if he's not allowed to manage the publishing of
the channel (see slide.channel.can_publish field).
This commit will hide the widget on both the slide.channel and the slide.slide frontend
pages if the user doesn't have the right to publish/unpublish. A generic solution
implemented directly in the publish mixin has been chosen to ease understanding
and allow easy reuse in other applications.
Commit linked to task ID 1902304 (main elearning task).
closesodoo/odoo#31187
Purpose
=======
The "publish/unpublish" widget is always shown on the frontend as long as the user
is a website_publisher and the object has a "website_published" field.
In some modules (namely website_slides) we need to handle a more refined level of access.
This commit adds a "can_publish" computed field that can be overridden to add some additional
access rules to the object and hide the widget if the user doesn't have the rights to
publish/unpublish.
When creating a pos session we try to link the session to
the first cash journal we find.
The problem is that we cannot link a journal comming from another
company this is strictly forbidden by a constraint.
This is why we should make sure that we search only for journals in the
same company as the config.
Task 1913733
Purpose of the merge is to continue the work done from PR #30988.
This completes the website profile page, gamifies the under development eLearning [1][2]
and continues integration between eLearning and the forum.
This merge contains notably:
- Complete profile page with course progression detail and eLearning certifications
- Apply Karma gains on various action on the eLearning
- Allow to set the communication type on eLearning course at creation (frontend)
- Redesign website users page
See sub commits for more details.
Merge linked to task ID 1922159 (elearning gamification / website_profile)
and task ID 1940516 (forum comments) PR #31097.
[1] see task ID 1902304 (main eLearning task) PR #29876.
[2] see task ID 1936153 (new homepage for slides) PR #30770.
closesodoo/odoo#31109
As the eLearning (website_slides) is also using website_profile users,
the All Users page is moved from website_forum to website_profile, to be
useable in both forum and eLearning.
This page displays also the number of karma point, badges and certificates
of each user.
The users are sorted by their karma points and the first 3 users are
promoted on a podium.
Use span instead of b tag in profile page
Task ID : 1922159
PR #31109
For users viewing their own profile page on the website,
a new section 'Certifications' is added to the about tab.
Thoses certifications are the survey that activated certificate.
Task ID : 1922159
PR #31109
Since 556b6454dab07cdf716d404ec0db9aa51a09b165, channel can be linked to a dedicated forum.
But the link could only be done in backend, in the slide.channel configuration
For now on, website_publishers can create a new dedicated forum when they create
a new slide.channel.
Link buttons have been added in both forum and slide.channel headers to navigate easily
between them.
Fix the relation between course and forum in a model point of view.
Task ID : 1922159
PR #31109
To gamify the new elearning, karma can be gained on various actions
- rank a slide_channel (course)
- vote for a slide
- finish a course
This commit also fix the 'completed' computation on slide.channel.partner
Task ID : 1922159
PR #31109
Two new sections are added in the profile page : Completed courses and Followed courses
Thoses sections replace the former 'Courses' section.
Use span instead of b tag in profile page
Task ID : 1922159
PR #31109
Previously we'd `append` the extensions and odoo parent directories to
sys.path, however this means if an `odoo` is already installed in a
sys.path (e.g. global installation, or setup.py develop in a venv,
...) *that* will be used as the source of Python code (for autodoc)
instead of the Python source being synchronised with the rst, which
can lead to very odd behaviour.
Prepend the doc's stuff to the PYTHONPATH instead, to ensure they get
priority and the code matching the rst gets loaded.
Make UnknownNS more capable (of giving no fucks) so the documentation
builder blows up less on weird-ass code at module toplevels.
UnknownNS should probably be split out from NSDoc though, that requires
odd workarounds in `__getitem__`.
The 'scrap button' should be visible only if:
- The picking is a done receipt
- The picking is a not done delivery
- The picking is internal
TaskID: 1930221
closesodoo/odoo#30466
_reverse_move presents a critical performance issue when
unreconcile moves with a lot of account_move_line.
The issue is that `account.move` and `account.move.line` models are triggering computed fields/methods for each new
`account.move.line` added, computing all lines again and again.
Making a factorial performance issue.
For each line the function try create cash basis entries for tax/base lines and this is combined with all the
fields compute that exists on the model so this introduce a performance problem
The issue is that `account.move` and `account.move.line` models are triggering
computed fields/methods for each new `account.move.line` created isolated,
computing all lines again and again.
e.g.
_compute_matched_percentage at
https://github.com/odoo/odoo/blob/5e8289cfeaf52a1eac64bcc975b186f0b5f9594b/addons/account/models/account_move.py#L44-L62
Then for each line modified/created this compute is executed for all lines (not just the last one).
Now by using self.env.norecompute() and self.recompute() the problem was reduced.
Unreconciling an 'account.move' with 1576 lines with a payment takes almost 4
minutes when before this changes, the conciliation process seemed not to never
end.
Fix https://github.com/odoo/odoo/issues/30934closesodoo/odoo#31014
create_tax_cash_basis_entry presents a critical performance issue when
reconciling moves with a lot of account_move_line.
The issue is that `account.move` and `account.move.line` models are triggering computed fields/methods for each new
`account.move.line` added, computing all lines again and again.
Making a factorial performance issue.
For each line the function try create cash basis entries for tax/base lines and this is combined with all the
fields compute that exists on the model so this introduce a performance problem
The issue is that `account.move` and `account.move.line` models are triggering
computed fields/methods for each new `account.move.line` created isolated,
computing all lines again and again.
e.g.
_compute_matched_percentage at
https://github.com/odoo/odoo/blob/5e8289cfeaf52a1eac64bcc975b186f0b5f9594b/addons/account/models/account_move.py#L44-L62
Then for each line created this compute is executed for all lines (not just the last created one).
Now by using self.env.norecompute() and self.recompute() the problem was reduced.
Reconciling an 'account.move' with 1576 lines with a payment takes almost 4
minutes when before this changes, the conciliation process seemed not to never
end.
Fix https://github.com/odoo/odoo/issues/30934
In some exceptional circumstances, the computation of the remaining
leaves might lead to numerical errors, e.g. a very small but non-zero
number (e.g. 10^-17)
This value will be displayed in the name of the leave type because of
the `%g` used in the string format. To avoid breaking the translation,
we round the value.
opw-1935232
closesodoo/odoo#31245
When defining an ABA routing number with leading zeros (which is
possible), the value will always be displayed without them.
This is because the field is an integer. Since the ABA routing transit
number must be a nine-digit code, we automatically fill it with leading
zeros.
opw-1940138
closesodoo/odoo#31223
- Enable multi-currency. Company currency = USD, another currency = SGD
- Update the exchange rate
- Create a purchase journal. Assign SGD to this journal
- Create a purchase tax of 7.00 %
- Enable tax rounding globally
- Create a purchase receipt with the following values
62.04 @ 7% tax
7.29 @ 7% tax
An error occurs: 'Cannot create unbalanced journal entry.'
Each line of the receipt creates its own tax line, which is therefore
rounded => the total of the receipt is computed with a 'round globally'
configuration, while the taxes are computed with a 'round per line'
configuration.
This is because `apply_taxes=True` is set in the context. This creates
the tax line by forcing the rounding. Therefore, we call the method
`_apply_taxes` explicitly in this specific case, and manually round the
taxes once they are merged.
opw-1938623
closesodoo/odoo#31194
We extract the tax creation from the AML creation in an external method,
in order to be able to call it separately.
This is necessary for the subsequent commit.
opw-1938623
Before this commit, when new messages were posted in a new
livechat, the operator received them after a delay. This
may take up to a minute before receiving the notification.
This behaviour was causing a bigger issue: those notifications
may never be received by the operator. This case happened when
the operator was receiving more recent notifications while
notifications from new livechats were pending.
The delay was caused by the operator not yet subscribed to
notifications on the newly created livechat. It is only on
the next poll of longpolling that the subscription occurred,
then followed by dispatching the notifications to the operator.
This commit fixes the issue by dispatching new messages of new
livechats directly to the operator. This is done by enforcing
the operator to make another polling when a new livechat is created,
so that he is always subscribed to those livechats. As a result,
new messages are received instantaneously.
opw-1933951
closesodoo/odoo#31191
This commit has been backported in 11.0 [1] and then reverted [2],
because it introduced a regression in web_studio, discovered at opw-1947380
As no forward-port has been done between the backport and the revert,
the forward-port of the revert also contains the patch itself, resulting
in a noop.
Actually revert 06d73eab62 in branch `12.0`.
[1] d855e3911f
[2] 1748b46718closesodoo/odoo#31637
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, when printing an invoice, the taxes were grouped
by their tax group (NOT by their parent tax)
Summing the base of each tax in the process.
This was largely insufficient, as tax groups can have taxes
with different rates or computation method within them
The summing of the base of each tax for reach tax group was in this case plain wrong
This commit aims at grouping by
group > computation method > amount
Which makes more sense
OPW 1947202
OPW 1945353
closesodoo/odoo#31617
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When duplicating a project, every task linked to the project is
duplicated too but the link between sub-tasks and their parent
task is not updated thus they are left linked to the task of
the original project.
opw-1937371
closesodoo/odoo#31154
When duplicating a journal, the alias is kept. Therefore, when the user
tries to change it, it updates the value on both records.
opw-1941717
closesodoo/odoo#31242
If the stage breadcrumb on the portal view is too long, it could get on
two lines but since they are righ-aligned in inversed order, the second
line (or more) will be the first stages.
With this fix, the breadcrumbs are left-aligned so on two line the
second line are the last breadcrumbs.
Also there was possibly a different order than backend since the order
is on "sequence, name, id" in backend but was just "sequence" here.
opw-1934497
closes#31237
Christophe Matthieu