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
- Create 2 companies C1 and C2
- Assign User U1 in C1
- Assign the default Sales Team (`sales_team.team_sales_department`) to
C2
- Create an invoice with U1
An `AccessError` is raised because the user is not allowed to access the
default Sales Team.
We fall back on `sales_team.team_sales_department` only if the user has
read access.
opw-1876966
This replace the antiquated openerp_mailgate script.
This version only supports mail.alias, direct model support is deprecated.
Error handling is based on exit status code which will cause a bounced mail
to be generated by the mail server, that bounced mail will containt a nicely
formatted traceback to help debugging.
* comparison
There is a somewhat big difference between BS3 and BS4: <h5> titles
were the size as normal text and <h6> were smaller while, now, <h5>
titles are a lot bigger (1.25x) than normal text and <h6> are the
same size as normal text.
While both system may be consistent, we feel that standing for BS4 is
the best approach. That way, the smallest <hx> (<h6/>) should be used
for titles of items that are numerous in the page. This is the case
for our shop listing, each product as its own title and before, we used
<h5/> element. Using <h6/> for those feels semantically more consistent
and goes with default BS4 style.
Also review the product comparator popover.
Before BS4 migration, Odoo was not very consistent and used mainly
btn-sm buttons and btn-xs buttons. We took advantage of the fact
BS4 removed the btn-xs class to convert our btn-sm to standard btn
and our btn-xs to standard btn-sm.
While this is perfect in theory, the new btn-sm class does not
generated small enough design for us. This commit changes the BS4
standard style for our website, making btn-sm smaller.
qsm-odoo