This rev. allows to navigate, in mobile, through records in form
views by swiping.
We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).
Related to task #34727
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Placing a list-group inside an element whose text color is forced is
buggy as the background of list-group items is forced to white and
the text color left untouched.
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
activity.js was a little dirty with a lot of copy paste.
Most of the common logic is now in a BasicModel.
This commit also add some tests on activity view
Co-authored-by: RomainLibert <rli@odoo.com>
Previously we required one or the other to be active. We removed this limitation for SO, thus the default value should be the company setting for both on the template as well.
Task: 1876864
PR: none
This reverts commit 6e8f1fcc63.
Reverted commit broke more than it fixed.
What it fixed : Show partner info when partner is changed after the
movelines are created (very specific used case, could be considered to
be the wrong way to do things)
What it broke : dropshipping
Click on the employee app causes a traceback when hr_holidays is
installed.
With this commit, leave_date_from and leave_date_to receive a date as
expected instead of a datetime when computing the leave status.
When users create new productivity losses of type productivity or performance,
they could not be used. Only one is selected randomly. So it makes no sense to allow
that configuration.
Related to task: 58625
Rename 'Reason' in 'Blocking Reasons'.
Rename 'Effectiveness Category' in 'Category'.
Remove 'Is a Blocking Reason'.
'manual' field become a technical field.
workorder: Change label Efficiency -> Productivity.
The purpose is to make it easier for the user and remove
blocking keywork since it's already in productivity losses views.
Related to task: 58625
PR #23341
Before this commit, a crash occured when you tried to load
a bar chart without any data.
Example in Purchase -> Reporting.
Since this commit 3d2ca810, we do some data processing without
checking if data exists.
To fix this, we have to always makes some checks before rendering
the graph by calling _render.
Move the operation type field from the additional info tab because
it's mandatory field so user have to know before saving fill this field.
TASK-ID: 1838954
The test was comparing a scheduled date was correctly computed.
The runbot build 363053 failed because runbot12 is a bit slower and computed
the delay in 2 seconds instead of the 1 previously tolerated.
Increase the delta to 10 seconds.
The delay is a matter of days. Having a difference of 1, 10 or even 100 seconds
should be equivalent functionnaly.
Having a 100 seconds delay could indicate a serious performance issue though...
Use case specifically for round globally, but the justifications hold anyway
Have a session with one tax, multiple partners, and returns of freight (negative amounts)
When validating a pos.session, the computation of amls was a bit out of logic,
Namely, we grouped tax lines by :
1. their tax id (correct)
2. their partner_id (not wrong but limited)
3. their balance > 0 (wrong)
The justification for point 2 and 3 is two fold:
- Ultimately, the order is level of granularity that really makes sense
It's the order that is paid and therefore that has both legal and business meaning
and on which the amounts are retrieved anyway
- On the order, we litterally make the sum of tax amounts of each line, aggregating
credit and debit under the same variable
It is only logic to do the same for grouping the taxes at validation time
This commit only corrects the behavior for the rounding method 'globally'
OPW 1865700
closes#26203
