In some case we don't want to wrap the content to be centered.
Now, you can add a data-nowrap when you define the theme params to
don't wrap it in a table automatically
Eg:
<div data-name="blank"
data-img="/xxx"
>> data-nowrap="1"
data-images-info='{...}'>
- Set your timezone in Brasil
- Install the Maintenance module
- Create a Maintenance Request, set the Requested Date to 2017-06-15
- Save
In the chatter, the track fields message shows a Requested Date of
2017-06-14.
This can actually happen with any date tracked. The issue comes from the
web client: it converts the date in UTC, which should of course not be
done. This only applies for a datetime, not for a date.
opw-746216
Field widgets must format and parse values according to the widget
type, not to the field type. For example, if a monetary field is
inserted in a form view with widget="float", the field's value must
be formatted with the float formatter, not the montetary one. This
wasn't the case before this rev.
Before this commit, the JS parser would add 0 after the input, then add the ean key.
Whereas reportlab.graphics.barcode fills the input with 0's on the left, then add the key
http://pydoc.net/Python/reportlab/2.5/reportlab.graphics.barcode.eanbc/
At: Ean13BarcodeWidget.__init__()
This commit makes the ean parser coherent with the lib the python uses
Commit 9966e4b added calls to preventDefault() on the keydown event
for left, right, up and down arrows, to prevent the page from
scrolling. However, it also prevents the cursor from moving inside
the inputs. Since the initial issue only concerned checkboxes, this
rev. moves the preventDefault() calls from AbstractField to
FieldBoolean.
Inspired by d7939282e9. Without this you
end up with a URI with a length of over 50000 characters. The default
template doesn't actually use any fields on pos.config so we could
theoretically get rid of everything. But because it's easy enough we
just get rid of relational fields and the customer_facing_display_html
field itself which make up the vast majority of the URI.
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).
Test cases contributed by @jir-odoo
Cherry-pick of be9dce625c
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.
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.
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
Purpose
=======
The new kanban status history in the chatter is not clear for the end user.
Specification
=============
When the state of a task is change the chatter should display the kanban state custom label instead of the kanban state
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`.
Martin Trigaux