Empty forward-port because commit 21f93b8035
is only a backport that does not need to be forward-ported again.
The point of this fwd-port was to resolve the conflicts immediately.
Low-level methods have to convert datetime into a naive user timezone
in order to match the attendances and leaves. Returned values are already
in UTC ready for display. Therefore no postprocessing is necessary for
output.
Planning hours can be done forwards or backwards. In first case the
returned datetime should be the last one aka the date when the job is
finished. In second case it should be the first one, aka the date when
the job begins. Those are the dates user want to know and manipulate when
programming working hours.
Manual forward port of 577eb10c0b .
Commit 57b8b9a057 changed templates used in recruitment. However we try
to stick on using the main model name when naming templates. Templates
subject may be whatever you want but templates should use main model as
name to order them and ease their use.
Account demo data try to add lines to payment terms. However when
reinitializing the module similar lines are added and a constraint
raises as there should not have duplicates. This commit voids
payment terms before refilling them.
Planning hours can be done forwards or backwards. In first case the
returned datetime should be the last one aka the date when the job is
finished. In second case it should be the first one, aka the date when
the job begins. Those are the dates user want to know and manipulate when
programming working hours.
When printing the sales details of the day in the point of sale interface,
The orders printed were the orders of the UTC day, not the orders
of the day within the user timezone.
opw-745273
'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
Website content is not supposed to use flex as it is not supported by
some old browsers. This commit provides a way to use flex only for
browsers which support it. When designing a snippet, you can use flex
to design elements and then write other style for when flex is not
supported.
Using flex should however still be avoided when possible. But hopefully,
this commit will allow to build greater snippets whose ugly non-flex
style can be disabled on demand or dropped in a future odoo version.
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
website_sale_digital overrides a method defined on
website_portal_sale, but only depends on website_portal and extends
the base controller from website_portal. Depending on the (relative)
order in which the system decides to load website_sale_digital and
website_portal_sale we can end up with the former's template but the
latter's methods (without the proper context data). Which ends up
commonly crashing in P35.
Fix dependencies and controller inheritance.
When adding a Python constraint on a (relational) field which uses an
other (relational) field, the order in which the fields are written is
also the order in which they are checked, and if a constraint depends
on a sibling field this might blow up in P3, here as in as in
test_new_api.message.Message (_check_author constraint depends on
parent discussion's participants): test_11_stored would commonly fail
when creating a discussion with two participants and 3
messages (because the message's authors would be checked before the
participants had been associated with the discussion).
test_00_sale_stock_invoice would blow up in Python 3, because the
test(s) relies on the iteration order of the products dict to know
where which line is (holy mother of caca) an set the relevant line's
data by indexing directly into it.
This would fail (with very odd results) in Python 2 and 3 as it could
set information on the "wrong" order line aka the order line for a
different product (and invoicing mode/whatever) than intended.
Fix the issue by hard-coding the products iteration order (to the
iteration order I get in Python 2.7.10 on that dict literal) using an
OrderedDict.
Python 3's hash randomisation means columns can be iterated — and thus
initialised — in any order (within a given model/override anyway),
which means there can be an implicit dependency on column
initialisation order e.g. (res.company).currency_id has a default
which fetches the currency_id of the company_id of the administrator,
and res.company has a _order=sequence,name, if the currency_id field
is created before the sequence the SELECT query will blow up as the
sequence column will not exist yet.
Attempt to always manipulate (iterate & initialize) fields based on
their order of definition using a global sequence number.
* Have the cleaned up style attributes be dumped in the same order
they were originally so that we can easily validate against text
content.
* While lxml's attributes are stored in an ordereddict, namespaces are
not and thus when comparing text serialisation of namespaced
documents the ordering of namespaces can differ between runs.
Fix by comparing the LXML trees directly.
Richard Mathot