NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
If some required fields are not present in the created values, they are computed
based on the onchange.
This was introduced at 5c4765130 to allow to import sale order lines without
specifying uom.
If sale_margin is installed, the same issue will occure as it assumes there is
a value for product_uom
Add test, courtesy of Mourad Elhadj Mimoune, Akretion
Closes#17613
This reverts commit 174d7e8e49.
The default language is the language if no lang corresponding to
the current language is found. Thus the browser language if available in
languages has priority over the default language.
opw-746776
closes#17637
With the new views, the class `o_field_widget` is added on every field widget
and is styled with `display: inline-block`.
The dashboards used to display graphs in full-width so this behaviour is
restored.
This option hadn't been implemented in the new views.
It allows to display informative explanations as tooltips on column over.
It can be set on a many2one field in the kanban view, e.g.:
```<field name="stage_id" options='{"group_by_tooltip":
{"<tooltipFieldOnStageModel>": "<ABeautifulTitle>"}
}'/>
```
An extra RPC needs to be done on the many2one relation to fetch these additional
fields and the data are stored in the datapoint under the key `tooltipData`.
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.
Similarly to functions `format_date` and `format_tz`, we add a function
in order to format amounts in the mail template.
It can be used, for example:
`${format_amount(object.amount_total, object.pricelist_id.currency_id)}`
opw-746088
Bug introduced with the latest forward-port. Since the invoice's workflow has been removed in bc8d5dbf2c, the button name to cancel an invoice changed also.
Original commit (in 10.0) be9dce625c
From original commit:
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Also, a key of context has been added which authorizes the process described above in the case of both a tracked product and no lot_id on the stock inventory
OPW 743107
Closes#17167
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.
When using Wi-Fi the Odoo instance on the POSBox will start after a
Wi-Fi connection is established. This takes a bit longer than when
you're using a wired connection. If Firefox gets started before you
end up with a 'Could not connect to localhost:8069' error.
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)
Before this commit, the return flow in the pos would not work if closing the pos session intervened before the return payment registration.
The balance of the the statements was not updated before going to the validate step.
After this commit, we force the recomputing of the relevant fields (i.e. balance_end_real), to reflect reality and permitting validatioon afterwards
Backport of e27a3b185e (on #17438)
Closes#17599
OPW 743763
Steps to reproduce the bug:
-create a child contact of a company C
-invite the child contact as a portal user
-sign into the website and place an order w/ wire transfer as payment acquirer
Bug:
The payment term set on the quotation was not taken from the company C and
the default sales person was not taken from company C too.
opw:745091
Before this commit, the return flow in the pos would not work if closing the pos session intervened before the return payment registration.
The balance of the the statements was not updated before going to the validate step.
After this commit, we force the recomputing of the relevant fields (i.e. balance_end_real), to reflect reality and permitting validatioon afterwards
OPW 743763
Closes#17438
Issue: when using `copy` in a given lang, the value of XML/HTML fields is
copied in its translated form, making existing translations useless. Fix the
value of such fields by storing their original value instead.
When doing a delete, the cache is cleared, putting an unlink in a loop
multiplies the number of requests made (for access rules, relational
field, recompute ...) by the number of rows. Doing it outside the loop
speeds up the validation of the invoice.
Backport of 10.0's 2687571781
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.
When doing a delete, the cache is cleaned, putting an unlink in a loop
multiply the number of requests made (for access rules, relational
field, recompute ...) by the number of rows. The use of a mapped improves
the speed of validation of an invoice.
- Activate multi-currency
- Define a rate today (e.g. 2017-06-01) and next month (e.g. 2017-07-01)
- Create a deferred revenue on 2017-07-02 in the foreign currency
- Post the first line
The rate taken is the rate of today, not the rate of next month.
opw-745509
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 .
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.
Olivier Dony