In a warehouse, mostly most of the products have no lot. It stays
important however to avoid having old products in stock, certainly if
we can distinguish them by pack or location.
As now in stable, in_date is not put on the quant for non-tracked products,
databases might mix quants with and without in_date of the same product.
We should see those without in_date as the oldest.
That is why we need to be able to apply a ASC NULLS FIRST (ASC is NULLS LAST by default) for FIFO
or DESC NULLS LAST for LIFO.
In order to do that, we copied the code from the _search method of the ORM to
be able to do this special order as the orm itself is restrictive as it
supposes the order itself has no spaces.
We adapted and added some tests to check it handles the combination of NULL/NOT NULL well.
- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
Nothing prevents to click on the 'Pay Now' button, although the shipper
rating has failed. Moreover, the error is not displayed in the label of
the shipper.
Workaround: we force a click on the selected default shipper to trigger
the update. The good solution would probably be to have a completely
dynamic shipper rating integration, instead of some processing at first
rendering and then extra dynamic processing.
opw-1838765
When we selected an image/icon, there was no visual feedback explaining
to the user that the image/icon had been selected (except for images on
chrome).
task-35020
Closes https://github.com/odoo/odoo/pull/24160
When clicking on button "Invoices" from a payment, it always displayed
the supplier views instead of taking care about the type of the payment.
opw:1849397
Purpose
=======
The method _name_search and _search add support to search as another user.
All the overrides of name_search and search redefine the behavior of the search.
This bring inconsistencies as the result of a call to _name_search and name_search
could differ on certain modules, which is not acceptable.
Specification
=============
Example:
~~~~~~~~
If the name_search method is overridden to search also on the driver name,
then calling name_search with a label 'JF' will return all the cars with a name containing
'JF' or all the cars with a driver name containing 'JF'. Let's say that we have a ir.rule
preventing a user to read the cars of another company. Then the call to name search only returns
the cars satisfying the previous condition AND belonging to his company.
Now, we want to overpass this constraint. We call _name_search with the attribute name_get_uid=1.
Then the call to _name_search returns all the cars from all the companies with a name like 'JF',
but nothing is done about the driver_name.
Example of wrong search redefinition on a model
-----------------------------------------------
@api.model
def name_search(self, name, args=None, operator='ilike', limit=100):
domain = args or []
domain = expression.AND([domain, [('name', 'ilike', name)]])
partners = self.env['res.partner'].search([('name', operator, name)])
if partners and name:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partners.ids), ('driver_id', '=', False)]])
rec = self.search(domain, limit=limit)
return rec.name_get()
Example of correct search redefinition on a model
-------------------------------------------------
@api.model
def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
domain = args or []
domain = expression.AND([domain, [('name', operator, name)]])
partner_ids = self.env['res.partner']._search([('name', operator, name)], access_rights_uid=name_get_uid)
if partner_ids:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partner_ids), ('driver_id', '=', False)]])
rec = self._search(domain, limit=limit, access_rights_uid=name_get_uid)
return self.browse(rec).name_get()
The same logic should be applied on the overrides of the search method.
With this commit, we introduce a better screen to manipulate the search
view in a mobile device.
Note: most of this work was initially done by suh-odoo, then was adapted
and moved to community by myself.
task 31464
For historical reason, purchase depends on stock module. We now
plan to add purchase feature for services. A service company will
not be interessted by having stock install when they do service
purchases. So this commit breaks this dependency by creating a
new bridge module named 'purchase_stock'.
No functionnal behavior should have changed, this commit only
move code.
However, some points need to be highlighted:
* The purchase report was split, the same way sale report is. Installing
stock will just add a few addionnal informations to the SQL views.
* Since test cases depends on stock demo data, the basic purchase
addon does not contain tests, but this will come in futur tasks.
* consu and service product's receieved quantity can be manually edited,
when stock is not installed. The same mecanism to compute this quantity
done
in sale (for delivered qty) will be implemented later.
Thanks to @amoyaux and @pimodoo for their reviews.
Task #47927
When stock is not install and using purchase alone, user
should be able to edit received quantity manually for
consummable (and services) products.
This is a direct consequence to the split of purchase
and stock module.
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
The idea is to do like the sale report: being
able for other modules to extend the report and
add their own fields. As we are going to split
stock from purchase, we will need this.
Revision on 8ac98fc78a
The commit above does not check whether the list contains data or not.
As a result, if there are no data in the list, there is no reason to
fetch `name_gets`.
In fact, there could be a traceback because some parameters of this rpc
are computed from data in the list. So if there are no data in the list,
the parameters of the rpc are undefined. This was the case for a test
in enterprise.
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
When seeing the work orders view, it would display an empty black box instead of
the proper message.
The message is not displaed since creation is deactivated.
opw 1839001
Have a delivery for a client, with pack operations
Connect on this user's portal
Go on the SO and then on the delivery
Before this commit, there was an Error 500
because access to fields of pack_operations was forbidden
After this commit, the report downloads well
OPW 1849520
closes#24849
datetime.date(year, month, day).weekday() is undefined for year > 9999.
When creating a google recurrent event that is set to never end,
Odoo tries to create 100 individual events.
If in Google calendar the user sets a recurring event to a custom interval,
of say a century, then the hundredth event is in 100x100 years, so in 12018.
Since 12018 > 9999, we get a traceback and synchronisation never happens.
opw 1845311
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
When we perform a planned transfer (which is the default behaviour now)
we are not able to set a quantity done on move lines in a confirmed
move because, the field 'is_initial_demand_editable' is true but should
not.
To fix this, we set 'is_initial_demand_editable' to true when it is not
a planned transfer AND the state of the move is draft, which is the
desired behaviour.
This behaviour come from rev:https://github.com/odoo/odoo/commit/ffb79761c1225c8a9c9303db4781f1b40b5d9944
When a picking is returned, the scheduled date stay unchanged. This date can be
in the past if the return is made at least one day after the transfer. This commit
set the return day as scheduled date
When a picking is in 'Done' state, we add the effective date on the form in
addition to the effective date. The user can know the date when the picking was effectively
made.
Starting with the 1000th user, the kanban view returns the id value
as '1,001', which, for some reason, does not go well when trying to
find the attachment by url...
Use `raw_value` instead, which does not format the id value.
Depending on the situation, it is possible to have move with origines
and destinations that have a loop.
A simple example is a return of a return, the origin and destination of
the return of a return is the return itself.
opw-1845444
closes#24787
Purpose is to avoid mixing various data types in the same generic mail_data
file. We already have 2 crons and the upcoming moderation feature will add
some more. Let us put them in their file to ease the finding.
This commit is linked to task ID 29521.
This commit provides a test suite for sale flow and unit tests.
We split tests in different files to try regrouping them by
testing purpose:
1/ test_access_rights.py checks employee, sale person, sale manager
and portal access rights. It is executes in post-install mode to be
sure other addons does not break the security rules.
2/ test_onchange.py checks the onchange using the SFF mecanism in
order to simulate what a sale person really does in its day-to-day
job.
3/ test_sale_pricelist.py execute a sale flow with different pricelist,
as this is a delicate aspect.
4/ test_sale_to_invoice.py contains tests about refund, discount and
downpayment, as none of those were tested.
Task #43928
As 'invoice_ids' on sale.order is a computed field, creating
a refund should invalidate this field as 'invoice_ids'
should contain invoices, refunds, ...
When using the refund wizard, the credit note will be linked
to the SO lines (see `_refund_cleanup_lines` override in sale).
Without the new trigger, invoice_ids will not be recomputed, and
executing 'sale_order.invoice_ids[1]' will not return the refund
account.invoice.
This commit fixes it.
`currency_id` variable is a recordset, so stop browsing it again !
In the meantime, if those variable had a meaningfull name, this
error would never occured !
Coming from 7a282c9965
Without this commit, reading all fields of sales
order will raise an access error if user does not
have access to hr.expense documents. An since
the expense count is displayed on the form view, this
can be annoying.
This commit makes the computation of the expense
count done by 'sudo', as there is not critical
informations at stake.
In some case, (e.g.: demo data), datas_fname is undefined and match of
undefined will crash and block the modal to be opened.
Uncaught TypeError: r.datas_fname.match is not a function
Set the right employee's possible states.
Before the restyling, the main title was always “Welcome!” regardless
of the user state (checked_in or checked_out). Using conditional titles
has exposed the issue.
Before that, the following scenario (tested in purchase/tests/test_anglosaxon_valuation_reconciliation.py) failed:
- create a PO
- change of currency rate
- create and validate vendor bill in foreign currency
- receive goods
- change of currency rate
- return the goods
- change of currency rate
- refund the bill
At the end of it, both invoices (bill and refund) were not in 'paid' state, but they should have been! The anglosaxon stock valuation code had some issues in the way it managed currency rates. The main one was that we converted the computed valuation_price_unit variable in company currency using the date of the invoice as a reference, which was wrong in case the invoice was a refund, as it should then use the date of the valuation for this. This problem caused the code to detect an exchange rate difference between refund and valuation as a price difference, hence generating a line in the price difference account, which caused the debtor account line of the associated account.move to be wrong, and hence impacted the residual field of the invoice ("amount due", in GUI). Finally, as this field contained an inconsistent value, the refund invoice was not marked as paid after reconciling it with the original one.
Solving this needed to refactor the code quite a bit, so that we don't convert everything in invoice currency in the end, but rather do it directly everytime we compute a part of valuation_price_unit. The test had also to be partly re-written as it was too naive in the way it used currency rates, we needed something closer to a real utilisation of the program.
- Create a Finished Product tracked by SN
- Add a BoM with routing (in several steps) to that product: component A
should be consumed in 1st step and component B in 2nd step
- Create a MO, plan it, go on the first WO and produce the finished
product with SN 0001
- Then go on the second WO and produce the finished product with SN 0002
- Back on your MO, you'll see that
Finished Product = SN 0002
Component A has been consumed for SN 0001
Component B has been consumed for SN 0002
- Mark the MO as done
No blocking error is raised so I'm consuming a product for a finished
product I'm not really producing. Traceability report will be wrong too.
We raise a blocking error to avoid this use case.
opw-1832098
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Laurent Smet