For some reason, it was lost. Probably in the graph view/pivot view split.
This commit simply accepts the attribute, but default to true, so nothing
changes unless you have explicitely set it to false.
Also, fixes en error introduced by a forward port (the use of
openerp.web.format_value)
automatically try to detect type of columns from the first 10 rows of file:
If column only contains integer, only show, int, float, monetary, m2o, o2m, m2m fields in wizard
If column only contains true/false values, only show boolean fields in wizard
etc
add an advanced mode which is the same as previous import (show all fields)
Support different date format and float value with currency as well as float value with parenthesis to reprensent negative value.
The editable list view method 'edit' is supposed to wait for the
record to be completely loaded. But when loading the defaults values,
it ignored the actual loading and completed too early. This commit
chains the deferred with the form record.
I recently removed some rpc from init fieldmany2manytag (it was in a
mutex) and moved it to the willStart method (without mutex). The
fieldmany2many tag widget needs this information before it can be
rendered. However, in editable list views, the rendering engine does
not wait for the fields to be ready before completing its initialization
process. As a result, the field many2many tag was rendered before it
was ready, which broke various things, including its position.
This commit attempts to bring sanity to this issue by making sure that
the rendering engine waits for its fields to be ready. Also, the
editable list view should detect correctly when the form is loaded.
If this commit introduces new issues with the editable list view and
onchanges, I will not be pleased. You don't want to bring me this sad
news without at least something to buy my good will.
We have an interesting problem when editing all custom float fields and all
fields with no explicit digit attributes: the propertiesmixin tries to
check if the number was changed, according to their declared precision.
But for these specific fields, it does not find a digit attribute, and
defaults to 2. Then, it makes sure that the changes are ignored if the
new value is too close to the old value (with 2 digits precision)
For example, if the user sets the value to 1.234, then save, then change
it to 1.235, then save, the form view will display 1.234 and totally
ignore the change.
Not that handling the digit precision is done in the propertiesmixin and
in the field float widget. Also, they do different things, and in some
case, may not be the same. All this logic should be moved to the
fieldfloat widget.
When exporting text data in CSV format, values
beginning with '=', '+' or '-' will usually be
mistaken by spreadsheet applications as formulas
upon CSV import.
That will often cause the cell to display an
error message instead of the actual contents,
such as "#NAME?"
Prefixing them with a single quote makes them
pure text cells. The special single quote
character is usually hidden by the spreadsheet
in that case.
Numbers and other types of values are not affected.
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
the widget FieldMany2ManyTags does a rpc to fetch the fields (just to
know if 'color' is in the model...). It was done in a mutex and used
later in a mutex. This commit simply use the willStart method to make
sure the data is available before rendering.
In 9.0's 05adb7f the `<div class="address_format"/>` wrapping an address
city, state_id and zip fields was removed.
There is a hack on fields_view_get which transform this block depending
on the company country, so without the block the feature isn't enabled.
This commit adds a class on the new block `<div class="address_format"/>`
used to wrap the whole address which will change the sizing of the city,
state_id and zip fields as it was before version 9.
To fully follow what was done previously, the zip is aldo moved before
the city if the address format needs it.
Thus we now have as before the three format as follows:
[default format]
city state zip
[format .o_city_state (brazil)]
city state
zip
[format .o_zip_city (belgium, netherlands, ...)]
zip city
state
Another change is brought by this commit, before most element attributes
from city, state_id and zip fields were lost whilst doing the hack, now
they are all kept.
closes#10692
opw-666567
Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
A special case for X2ManyKanban views was handled in the Kanban view itself.
This commit makes the X2Many case identical to the general case by setting
options.action_buttons to true if the X2Many field is not readonly.
Christophe Simonis