When clicking on the "manufacturing" vignette in the inventory
dashboard, the records were not filtered correctly (example: add a new
warehouse, a new "manufacturing" vignette appears for this warehouse in
the inventory dashboard, clicking on it would display the MO of all the
warehouses).
With this fix, as with the pickings, it will only show the count of MO
filtered to that specific picking type in the vignette, and clicking on
it will displayed the filtered ones.
We implementent the method of the compute field the same way the similar
method for the picking is implemented.
fixes#15008
Remove unused fields (including inherited view) in kanban project view,
For example, `user_id` triggers a read for each project on res partner,
40 projects display = 40 read on `res.partner`.
Closes#15096
Related to opw-696979
- Go in Events > Events
- Create or modify an event
- Add a ticket to your event, and try to change the product -> traceback
The field `event_type_id` does not exist on model `product.product`. It
has been removed in commit 7f97a64091.
opw-704838
Before this commit, website needed to be installed to edit
a HTML report because the context `inherit_branding` was not
correctly passed.
Credits to @sle-odoo
If node is not installed (missing dependency), the user is not aware of the
source of the issue as it can not be displayed in the css_errors or logger.
The error is
/usr/bin/env: ‘node’: No such file or directory
which contains unicode quotes.
Does not fix#15057 but at least say the source of the problem.
`set_multi` uses the company of the current user.
As the property is created in sudo, the company of the admin may be different
than the one of the current user.
Before this commit, setting a different pricelist on a partner when logged in a
different company than the admin, the change had no apparent effect (was
creating a property for the admin's company).
Set `force_company` in the context to always set the one on the current user.
set_multi ignores if the same as the global rule to avoid bloating the table.
Closes#14984
The price suggested thanks to the "Compute from BoM" button only takes
into account the price of the products listed in the BoM lines.
In v9, there was a "Recursive" option that provided the possibility to
compute the prices of all products implied in the BoM, recursively. This
option has been removed since it was leading to a "black box" behavior
that was unclear to the users.
However, limiting the price computation to the BoM lines only is too
restrictive since it doesn't even take into account the phantom BoMs.
By using the `explode` method, we have access to:
- all products not manufactured
- all products manufactured which are not kits (phantom BoM)
It means that the cost of manufactured products (not kits) should still
be computed before the product itself.
opw-697866
When a product template UoM is different from its BoM UoM, the price
suggested thanks to the "Compute from BoM" is incorrect, since it doesn't
apply the conversion rate between the product template UoM and the BoM UoM.
This is because we try to fetch the product UoM through the BoM. However,
if the BoM is not specific to a product.product, the field bom.product_id
is empty.
The issue is introduced by revision
d465346f1e
Raphaël actually meant
`res_ids = data.mapped('res_id')`
Indeed, there is no `res_ids` field on `ir.model.data`,
but there is a `res_id`.
In addition, the same code is written correctly in the method
just above this one, `_object_find`
opw-704592
In 07bf7bf4f3 a fix was introduced for windows server UTC timezone.
It is possible it would be helpful in some situation to also have it in
setup/odoo (for example if odoo was installed on windows in some other
way than the Installation bundle).
opw-693764
Invoices created automatically by the payment acquirer must use the
correct accounts/journals, which may not always be the case if not
explicitly set in the context.
In the worst case, user is not logged in and he will really have no access and
will have a perm read error after login. We cannot check if an unknow user has
access or not.
In most cases, user will be logged in and will see the document directly if
he has access or will be redirected to messaging if no access.
In the best case, he will be redirected to login page before to see the message.
task-22505
The forward-port of the above revision missed
the conversion to the new api and that
`context` had to be replaced by `self.env.context`
Fixes#14922Closes#14923
In the Lead Automation module, the module is working as expected when
the activity type is 'Email'. In other cases, the corresponding methods
are not implemented and raise an error.
opw-697829
According to the routes set on the products of the raw materials, a
procurement may have to be created for the consumed lines of the MO.
A route may also be set on a product category. Before this patch, we
only look for procurement rules for the routes defined on the products
and on its category, ignoring the inherited route of the parent category.
Fortunetaly, we have a computed field on the product model returning
all the routes from the current category, so we use this one in the
search for procurement rules.
A test has been added to show the failure.
Before, when the routing of a production order was empty (no operations),
it got into an inconsistent state (you click on "plan" and nothing happens).
Empty routings were used before to do subcontracting or 2-steps inventeory
(we did not set any operations on the routing but we set a location).
Here, we change the related routing field on the production order into a
calculated field which becomes empty when the routing has no operations.
This way, the "produce" button is displayed (as for production orders
without routing) and working/
This is a temporary patch to workaround the issuein a stable release.
In master, we might remove the location on routing and place it on the
workcenters and put a constraint that does not allow an empty routing.
Revision 20935462a0
introduces the below regression:
When registering a payment on a customer invoice refund
or a vendor bill, with a payment difference
e.g. payment of 101 for an invoice of 100
and marking the invoice as fully paid,
the counter part in the payment account move
were wrongly computed:
In those cases,
its the payment total minus the invoice residual total
that must be performed, and not the other way around.
This revision solves this, inspired on how
the payment difference is computed for display
in the wizard on how it was before the above revision,
in the method `_compute_payment_difference`
Fixes#15000
Before this patch, the inventory was automatically posted when you click
on "done" on the last planned work order. This behavior was preventing
the user from correcting, for example, the consumed quantity on the raw
materials move on the manufacturing order if it was different from the
theoretical quantity. Note that finishing anyone but the last work order
still let you edit the consumed quantity. Same with changing the lot.
Now you have to click on "mark as done" on the manufacturing order to
post the inventory. Note that this is the same behavior when working
without work order (produce > mark as done will post).
We adapt the tests to reflect this change.
In some case (for example the one solved with b51d21c5) we can have
write done on a field text in read only mode.
With 98ed53ce if :
- such a case happened (in b51d21c5 the fix only worked after the given
field was written one time) or a similar instance,
- and the user was in debug mode,
- and the widget used was TextFieldHtmlSimple
this could lead to an issue with the code trying to toggle the code view
mode whilst the editor is closed.
When doing pivot table data visualization, the Unit Cost of several
lines are summed up but there has more meaning if they were averaged.
This will probably still not be perfect (such as averaging two line
with different quantities the quantities would not be taken into
accounts) but it is already slightly better.
opw-694068
Suppose the following usecase: you scan the first product of the
picking. A server onchange is then triggered. You scan the same product
a second time, before the first onchange has returned. You expect that
the first onchange is completely executed before running the second one.
This was not the case. Moreover, some onchanges were not be able to
work with the invalid state of the formview at some times, and crashed.
The previous implementation was wrong because id didn't run the main
barcode processing mechanism inside a Mutex. It was also wrong because
it didn't correctly wait for the onchange to execute (a previous barcode
onchanges or some classic ones) before setting the barcode field.
Josse Colpaert