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)
In case of a sale receipt including a tax, the error 'cannot create unbalanced entry' was raised illegetimately. The reason was simply that the tax line was defining a debit instead of a credit.
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.
- Go to a contact C1 > Membership tab > Buy membership
- Create an invoice with the membership
=> It creates a membership line on C1
- Change the partner on the invoice to C2
The membership line and the membership status is not transfered to C2.
We first need to recompute on C1, and we also need to explicitly write
the new partner C2 on the membership lines.
opw-1875673
- Go to a contact > Membership tab > Buy membership
- Create an invoice with the membership
=> The status of the member goes to 'Waiting membership'
- Validate the invoice
=> The status of the member goes to 'Invoiced membership'
- Create a credit note to cancel the membership
=> The status of the member goes to 'Paid members'.
It shouldn't be the case because the client has canceled his membership.
We look on `payment_move_line_ids` instead of `payment_ids`. Indeed, the
latter doesn't list credit notes, while the first one lists all move
lines used for payment.
opw-1875673
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
In recruitment, clicking on configuration > job positions > kanban view
leads to an odoo client error.
The qweb template cannot evaluate the condition on the client side.
With this commit, the ternary condition is properly evaluated.
Also, an unnecessary t-attf is removed.
Closes#26486
This commit fixes two issues:
- If a partner has multiple users and if any of these users is a
share user, then the access button on mail notifications is not displayed.
- If a project.task is either assigned or has its stage folded
the access button may not be displayed for certain users.
The users affected by this bug are the one who have their user's
partner is linked to multiple users with at least one flagged as a share user.
Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
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.
TWA