The `o_status` style has been moved in a previous rev. in `fields.less` which
is only for `o_field_widget` nodes.
This class however is used in other context than a field (e.g. on a label in
the project.task.type form view) so its style needs to be placed at an upper
level.
Since commit ebd17217c4, values of readonly fields inside x2many
fields weren't sent for onchanges, whereas they should. This was
for example an issue on the stock.picking form view (which is in
state 'draft' by default). If the user added a stock.move, the
state field on the move wasn't sent for the onchange, and thus the
state field on the picking was set to false.
By the time the product images are downloaded the current order object
may have already been destroyed. This can happen when e.g. clicking on
the 'Next order' button.
With the new views, the merge task feature did not properly precomplete the selected tasks. This is because they do not support the command 4 when creating a new record. This will be fixed at some point, but meanwhile, we can just simply return the selected ids in the default_get. This makes the code slightly simpler.
(PR #17566, issue 746867)
When the user duplicated a record 'A', and deleted the new record
'A (copy)' directly, the wrong record was deleted: 'A' was deleted
instead of 'A (copy)', because de id of 'A' was bound to the delete
handler, and it wasn't updated after the duplication.
Also correctly updates the record's offset after the deletion, so
that it doesn't produce a warning when deleting the last record of
the dataset.
'id' is a particular field that should not be considered like other
integer fields. For instance, in the evalContext, its value should
not fallback to 0 if it is false. This would break domains in attrs
like ['id', '=', False], which is supposed to be true on new (not
saved yet) records.
This was for example the case in the Product form view: go to Sales
Orders form view, add a line, on the product field choose 'Create
and Edit', try to save the product -> error: field Product Template
is required but not set (actually it is invisible), as its required
modifier says ['id', '!=', False], which was always the case.
Ultimately, it seems that sending the value of readonly fields
when saving is not such a good idea. Suppose that there is a
computed field displayed as readonly in a form view. This field is
computed from other records, e.g. from a one2many field which is
editable in the form view. Finally, the inverse function of the
computed field creates the one2many records. If the user adds some
records to the one2many, then saves, the readonly computed field's
value is sent to the server as well, and thus the inverse function
is executed, which isn't what we want.
This commit essentially reverts 0494d61274, except that we now take
into account the readonly modifier to determine whether or not a
value is sent to the server, and not only the readonly attribute of
the field (which can be seen as a default). Before rev. 0494d61274,
we made a difference between write and create RPCs, for an unclear
reason. We don't do that anymore: readonly fields are never sent to
the server (same behavior as before the new views).
A problem occured with a required Many2One inside an X2Many (e.g.
order_line field in sale.order form view). If the user clicked on
'Add an item' to add a row, then typed some text in the Many2One,
then clicked on 'Create ...' to quick create a new product, and
then directly clicked on 'Add an item' to add another row (before
the name_create returned), the first row was discarded.
This was because before the name_create returns, the Many2one still
has no value, and as it is required, the row was considered invalid
and then discarded.
This rev. ensures to wait for the name_create to return before
trying to save the row and to create a new one.
Before this commit, it was not possible to reach the general settings when one
of the "default" provider was delete.
After this commit, we don't assume anymore that there are google and facebook
providers.
opw-746907
In a SO, the "Invoiced Qty" can decrease if the refund is generated from
the SO. It doesn't decrease if the refund is generated from the Invoice.
However, we don't have this mechanism in a PO since the invoice is not
generated directly from the PO. There is therefore no way to decrease
the "Billed Qty".
We authorize the "Billed Qty" to decrease in the case of PO.
Backport of c6a7e4fbb9Closes#17564
opw-747038
When an expense sheet contains several expenses with various currencies,
some issues arise:
- the currency is not specified in the form view
- the report mixes the currencies
- the total amount doesn't make any sense
Fixes#17341
opw-745714
When creating an account.payment via the form view, an onchange sets the
partner_type based on the payment_type (which has a contextual default)
and the field is view-required.
When importing however if the user does not specify a partner_type
(which they are not specifically told about) the payments will be
created with no partner_type and thus classified as "internal payments"
and will not appear in either the Sales > Payments or the Purchases >
Payments, confusing them and making them think the import has failed
despite having correctly validated and raised no errors.
Add a default_partner_type matching each action's domain (and default_payment_type) such that the imported payments are correctly classified by default.
OPW-746479
fixes#17388closes#17497
It shouldn't be possible to duplicate ir.model.fields. Add attribute
´duplicate´ which can be set to false to hide the duplication option in the
action menu.
The name of a company is uniq. The name of a company comes from a
partner and is required.
Thus duplicating a company didn't work.
With this change, if no partner is overriding the copy, the current
partner is duplicated and associated to the new duplicated company.
opw-746106
closes#17532
- Create a stockable and a service product
- In the POS, sell 1 unit of the stockable product and -1 unit of the
service product
- Validate and pay
2 pickings are created: a picking containing the stockable product which
stays in state 'Draft' and an empty picking in state 'Available'.
The problem comes from the negative quantity on a service product: we
should filter out services when checking the quantities.
opw-745712
It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
backport of 74a89bcf5c
Since we handle rouding error with the last line as
the difference of total and the other (already computed),
the order of lines to process is important.
Calling 'sorted()' on the lines to process allow
to always have the same last one.
Hope this will fix the random rounding bug, and make
the multi currency test always green !
When logging timesheet, no employee is set by
default on the UI. The employee is deduced
from the user_id in the create, but we want to
see it on the list view even if it is not saved
yet.
It's unclear whether that's a recent change or a long-standing issue,
however currently if geocode is called with an empty address string it
will reply with a 400 Bad Request, which gets raised as an exception and
forwarded to the user. That is not a great experience.
Shortcut the entire thing and just return None (= geolocation failed /
no geolocation) on trying to geolocate an empty address.
OPW-746686
Let's create in google calendar a reccurent event with all day
set and a end date.
When synchronising google calendar with Odoo(by clicking on button
"Sync with Google"). It raised on error because the start date had
a time zone but not the end date(the UNTIL in the rrule).
Fine tuning of 20ed57f
opw:746549
stock_landed_costs: on nightly, the localization installed may not have stock properties accounts defined. If it's not, we create them on the fly with a random account
sale, sale_expense: fix broken tests due to mismatch currency:
On 10.0-nightly, the currency of the company is not the same that the product.list0
that leads to assertion errors.
The karma link is an hardcoded page from odoo.com. The information might
therefore not be correct depending on the configuration of the user.
We change to redirect to the FAQ, which also contains Karma information.
opw-746383
Martin Geubelle