Add effective date on maintenance equipement. The purpose is to define
when the equipment is put into service.
Adapt next preventive maintenance according to effective date
Task id: 33188
Before this commit, if import from tests directory was not in the __init__ file,
it was not possible to launch it with --test-file cli.
Now we only check in test directory if file exists.
This commit closes#26500
Since 960360a, when computing badge stats, a datetime was compared to a
string leading to a traceback. e.g. when clicking in employess >
badges.
Also, due to a typo, the compute method was assigning the stats result
to the wrong attributes. e.g. 'stats_my_this_month' instead of
'stat_my_this_month'.
With this commit, the above mentioned issues are fixed and a test is
covering these issues to avoid regression.
The links without href attributes, have a different style, so we cannot
differentiate them from non clickable text. So we set the href attribute
and prevent the default behaviour of the link in js.
TASK-ID: 1873101
On stock production lot, we show stat buttons redirecting to purchase
orders and sale orders where the lot has been used instead of showing
Many2many in the form view.
TASK-ID: 1873101
When a final product move line is shown in the traceability report is
displayed, the reference to the MO is not displayed because the finish
products move lines don't have any productio_id on it.
So to fix this we take the production_id of the move_id when it's a
finished product, and the raw_material_production_id of the move_id when
it's a consumed product that are always set.
TASK-ID: 1873101
We now only show the move lines that are processed before (in date and
location) when we display the move lines from a picking or a
manuficturing order, before it was showing all move lines that
where processed before (only in date) meaning that if you display a
delivery, you were also seeing the other deliveries done before this
one.
TASK-ID: 1873101
PURPOSE
=======
Make the traceability report available in more use cases.
SPECIFICATIONS
==============
1. Traceability Button on Manufacturing Orders
There should always be a traceability report available on the MO,
no matter if the finished product is tracked or not.
Example 1 : finished product is not tracked
but the components are tracked
Example 2 : finished product is not tracked (qty>0)) but
the components are tracked
Example 3 : no products are tracked
Task id: 1861928
Before this commit, the 'is typing...' notification bar was sticky
to the bottom of the thread, independently of the ASC or DESC mode
order of threads.
This is okay for ASC, but not for DESC: it should stick to the
visible top of the thread for DESC.
As a result, this notification bar was always at the top of the
thread, without the 'sticky' behaviour:
+--------[top]--------+
| X is typing... |
| |
| (newer messages) |
| |
|- - - - - - - - - - -| <---- visible top
| |
| ... |
| message i + 1 |
| message i |
| ... |
| |
|- - - - - - - - - - -| <---- visible bottom
| |
| (older messages) |
| |
+------[bottom]-------+
With this commit, the 'is typing...' notification bar sticks
to the visible top of DESC threads:
+--------[top]--------+
| |
| (newer messages) |
| |
|- - - - - - - - - - -| <---- visible top
| X is typing... |
| ... |
| message i + 1 |
| message i |
| ... |
| |
|- - - - - - - - - - -| <---- visible bottom
| |
| (older messages) |
| |
+------[bottom]-------+
Revision on https://github.com/odoo/odoo/commit/0eab8f6e0b17a4ff6a859d14b14b643212cbadc1
The commit above fixed the definition of ASC/DESC on the rendering
of mail threads.
However, the 'is typing...' notification bar was still partially
using the old definitions. As a result, this notification bar was
not sticking at the visible bottom of the thread when there were
few messages:
+--------[top]--------+ <---- visible top
| 1st message |
| 2nd message |
| 3rd message |
| X is typing... |
| |
| |
| |
+------[bottom]-------+ <---- visible bottom
This commit fixes the issue so that the 'is typing...' notification
bar is always at the bottom of the thread in such case:
+--------[top]--------+ <---- visible top
| 1st message |
| 2nd message |
| 3rd message |
| |
| |
| |
| X is typing... |
+------[bottom]-------+ <---- visible bottom
Note that it fixes the case with 'few messages', without altering the case with
'several' messages:
+--------[top]--------+
| |
| (older messages) |
| |
|- - - - - - - - - - -| <---- visible top
| ... |
| message i |
| message i + 1 |
| ... |
| |
| X is typing... |
|- - - - - - - - - - -| <---- visible bottom
| |
| (newer messages) |
| |
+------[bottom]-------+
-remove margin
With the spirit of making tests determinists,
we can remove margins to have a real test of query count.
-mock random on assert query count
bus gc is triggered using random. Therefore, when send_many is called,
we have 1% chance to have more query. Mocking random.random to 1
will disable gc during query count tests (not during warmup).
Could be interresting to put gc collection in a cron latter
-add more info on querycount
Adding file and line number on query count failure/info will help to update
the query counts.
-update query count based on enterprise
Update all query count with enterprise values (exactly)
-normalize query counts with enterprise
voip module add a read on activity type (during create) in enterprise,
leading to one more query but also more information in cache.
Therefore, the next assertion will need one more query to access this data
in community.
Adding an access to activity type in the first assertion will allow
to have the same cache state in community and enterprise.
Task: #1878588
PR: #26476
This indirection is the only place in the whole codebase, which indirects in
this way.
This block downstream code which relies on:
- access to the line's company
- while not necesarily having access to the account's company
(being line's company different than account's company)
Disclaimer: This use case is not officially supported.
However, this indirection does not make sense under the currently
supported model, neither.
* [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
Akash Bhavsar