No technical or functional change. Only reorganizing fields to better
understand the model. Future commits will change a few fields in this
model and this commit prepares it by classifying a bit them.
Currently, if you create a manufacturing order, you can select
all the product that have a BOM. But some product have BOM that
are archived or that can't be manufactured.
This commit add a constraint in the domain for product field.
The constraint ensure that BOM are not archived nor phantom BOM.
It is confusing to see an existing payment transaction on an SO next to its
total even though it doesn't necessarily mean that the SO is paid because the
transaction could have failed. Additionally, if there are several tentative
transactions for one SO, only the latest one is accessible through this m2o.
Closes#16128
When the module sale_stock is installed, the MTO route is now by default
available on sale order lines.
We also remove the ability to create routes from sale order lines, as a
salesman will never have to configure new stock routings.
If a record is tagged with no update, the translations must not be replaced,
even if the "overwrite translation" checkbox is checked.
If somebody renames a noupdate and translated record, updating the translations
must keep the new translations.
Closes#14768
When posting journal entries for an hr.expense.sheet with several expense lines
(by clicking on the button "Post journal entries"), all the account move lines
created for the same sheet must be linked to the same account move because
the model hr.expense.sheet has just a field "account_move_id" to access all the entries
(by clicking on button "Accounting Entries")
This commit reverts f97eb0ac2b
opw:715523,709930,725798,716239
The domain field needs space to be rendered. Even with its "in_dialog"
option activated, the readonly representation can take some space.
If there is not enough space, it will be a mess to read it and the
"-> x records" button can also overflow the "Add filter" button.
This commit makes the field to be rendered as a "block", which fixes
the problem in all current cases.
In the kanban view, if the default_group_by is a many2one, it's possible
to quick create a new column (which will create a new record in the
relation model).
However, the field `name` was hardcoded during the creation, which means
that a custom model with `x_name` couldn't be correctly created.
This commit allows it by using `name_create` instead.
The alert box was flickering if empty: at each click on the status
button, the box was appearing and disappearing quickly. This is probably
due to a bug in the form view that do not wait for the evaluation of the
attrs. This bug is fixed in the new views, but only if the attrs is
fixed. Indeed, as the attrs condition is
attrs="{'invisible': [('production_messages', '=', False)]}"
the field was never set to False. This is because the compute method was
doing
workorder.production_messages = "<br/>".join(messages)
So, even if `messages` was empty, production_messages will be set to ''.
In [1]: 'aaa'.join([])
Out[1]: ''
So we fix the condition to set False to the field if the string is
empty.
In [6]: 'aaa'.join([]) or False
Out[6]: False
A 50 px height was hardcoded, so if you have more than 2 or 3 messages
they were displayed outside of the messages box. We remove this
hardcoded height and it looks better.
When there is a lot of texts to display in a tooltip, it will overflow
the viewport vertically as the max-width of the tooltip is set at 200px
(bootstrap default). This commit increases the max-width to the
viewport full-width.
opw-725804
Before this patch, #15920 was happening. The problem was that calling `render_cell` produced a call to [`record.set(column.id + '__display', value)`][1], which triggers the `change` event, which called `render_record` the first time, which called again `render_cell` and produced the 2nd data fetch.
After this patch, `render_record` is only called if there is some place where to put the result, which does not happen in those situations.
There is still the problem that there is one call to name_get for each many2many widget found in a list view (instead of one per full view rendering), but at least they are not two calls!
[1]: https://github.com/odoo/odoo/blob/5d17749ff47c02294d5ff2ae56bbcef9d082562e/addons/web/static/src/js/view_list.js#L1125
- Activate the MTO route on SO lines
- Activate the route "Buy" on a Product A without quantity on hand, add
a supplier
- Create a SO with 2 lines. First line is Product A, second line is
Product A with route MTO
- Confirm the SO, run the procurement if necessary
- Confirm the PO, receive the products
- On the picking generated from the SO, you should have one line
"Waiting Availability" (the line not MTO) and one line "Available"
(the line MTO).
- Click "Recheck Availability". One reserved quant from line 2 is moved
to line 1.
A trick is to assign first the move with ancestors, so we don't "steal"
the reservation on the other move.
Fixes#15950
opw-725373
In maintenance.equipment form view, the field owner_user_id has been replaced
by equipment_assign_to, employee_id and department_id. But in the kanban view,
this field was still displayed even though the image was replaced by the image
of the employee. So now, the kanban view follows the same behavior as the form view.
opw:724378
- Create a PO with a product "Control Purchase Bills" set to "On
received quantities".
- Validate the PO.
The invoice status is "Waiting Bills", while it should be "Bills
Received".
opw-726245
If you had a price with a tax included and the user has fiscal position.
The tax included in the unit price was not substract before the mapping.
Eg: product $115 with tin 15% included in price.
Once in the cart with a fiscal position intracom (0% tva), the unit price
should be 100$ and not 115$.
This commit closes#16022
What matters in sales reporting is the confirmation
date (signature, payment, etc), not the creation date.
All the sales reporting is based on order date
(= creation date). Most people need the confirmation
date (to grant commissions, etc.)