* [FIX] account_voucher: copy product/qty from receipt to journal items
Before this commit, product_id and quantity were not passed
to the aml from account vouchers.
This caused inexpected behaviour, if products are a relevant dimension in cost
or revenue analysis analysis: Whereas on invoices, this product is copied to aml
on voucher, it is not.
Was PR #26336 . Courtesy of David Arnold (XOE Solutions)
Before this commit, the web client in the JS tests environments
might be influenced by `longpolling/poll` or `mail/init_messaging`
RPCs. For instance, if we received a new direct message in Odoo
during some JS tests, it would open a thread window. As a result,
the tests on thread window will fail because of this newly and
externally added thread window.
After this commit, no service is deployed on the webclient on top
of the JS tests environment. This should prevent most undesirable
side-effects of RPCs, such as opening a thread window when receiving
a new direct message on the longpolling bus.
Impacted modules: sale, sale_margin, sale_timesheet, pos_sale
This speed up a lot reports like sale.report when multiple currencies
with multiple rates are used, even with few currencies and few rates.
Using `_select_companies_rates` in SQL view bring lots of JOINs,
which slow down the view generation. This commit adds a computed
stored field containing the currency rate at the order date to speed
up report generation (database schema denormalisation).
This commit also use this new column on sale.report extensions and on
the project.profitability.report in sale_timesheet module.
Since a4d6bff197, the pos.report is
included in the sale.report. So, the same change had to be
applied on the pos.order model.
Task #1877418Closes#25089
- The current code found colors in the page which were not custom colors
(because we were case-sensitive for hex values)
- Applying custom colors font font/background were inverted
Purchase orders created from purchase agreement behave differently depending on
the agreement type.
On one hand, if the agreement is a blanket order, the vendor must be set automatically on the
purchase order and be the same as the BO. Changing the vendor is forbidden.
On the other hand, if the agreement is a call for tender, multiple purchase order can be
created with different vendors. It that case, the vendor field must be editable in RfQ states.
This commit is related to task ID 1866975.
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.
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
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...
David Arnold