This allow the browser/device to handle the experience of handling number in a more native way.
FieldInteger and FieldFloat now inherits from NumericField because we want
to format it or not dependent of the view (readonly or edit) and the
NumericField will manage it.
We do that because input type number can't take a value with comma on Chrome
(FireFox is more permissive but not perfect because comma is the separator
for decimal in this case).
Task #1880376
The recently introduced `activity` view (see rev. odoo/odoo@1de9496 has not
received all the consideration it deserves as a real view type (no RNG, not in
the valid view `type`, no doc, etc.). It was currently only working based on a
`_get_default_activity_view` method.
Even if the RNG is currently really basic, its grammar could evolve in the future.
This was causing an issue when opening Studio with this view as a default view
with an invalid type was created.
doc:
* fix incorrect doc comments (documenting params which don't exist)
* correctly quote non-refs
* fix role label syntax (backticks must be escaped)
* add newline to fix warning
JS doc parser:
* fix handling of already-resolved objects
* fix handling of non-string properties (e.g. foo[0] at module toplevel)
* don't blow up if subject of .include call can't be resolved (just ignore)
Others:
* add translator support for ``problematic`` node (apparently used for
some refs by recent Sphinx)
This commit provides new js widgets for list, kanban and form
views on float field.
1/ 'float_factor' displays the normal float field, but takes a
conversion factor as option. The displays value is the normal
one multiplied by the factor.
You can use the widget like
<field name="my_float_field" widget="float_factor"
option="{'factor': 2}"/>
2/ 'float_toggle' displays a button (in edit mode) looping on a
range of given value at each click. A conversion factor is optional
(default will be 1) to display a converted value, but sent to
non converted one to the server.
You can use the widget like
<field name="my_float" widget="float_toggle"
option="{'range': [0, 0.5, 1], 'factor': 2}"/>
'range' and 'factor' are put in the options.
In simple read mode, the widget display the value as a traditionnal
text (like a normal char field).
This commit provides tests and documentation for those 2 widgets.
Task #39079
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Add a banner_route attribute to AbstractView to allow fetching html from a
controller route and displaying it above the view.
The initial use case was the onboarding panels.
Supported views are the ones inheriting both AbstractView and AbstractController.
The default "add a line" button creates a new line with the default values from the model. Sometimes we want to create a new line with different default values (or more generally a customized context), which is possible with this commit. Moreover it is possible to create multiple buttons for multiple default values/contexts.
This works both for in-line creation ("editable=") and dialog creation.
The new tags are:
<control> defines custom controls for the current view.
Does not support any attribute, but can have children:
<create> adds a button to create a new element on the current list.
This makes sense when the parent tree view is inside a One2many field.
If any create is defined, it will overwrite the default "add a line" button.
For more information and example, have a look at the Views documentation.
Technically, the commit will:
- parse the new XML tags (+ add appropriate validation)
- display the buttons based on the XML
- on button click/keyboard: pull up the additional context information from the button event up to the default_get
- add unit tests
- add documentation
PR #25209
We add the attribute default_order on the pivot view (already present in
graph view), this attribute will sort the pivot view on the given
measure.
Closes: #25675
Pivot view documentation was still inside the graph view documentation
as it was previously only a mode of this graph view.
As the pivot is now an entirely different view, it has the right to have
it's own documentation.
svs-odoo