Before this revision, the `char_domain` re-rendered its display
only when its domain value was changed.
It must re-render as well when the model on which this domain
is applied is changed, as the number of records can
obviously be different.
e.g., in mass-mailing, when changing the recipients type
from partners to leads, the domain doesn't change, it
stays `['opt_out', '=', False]`, but the model on which
this domain is applied does change, as well as the number
of selected records.
opw-658391
'write_function' transfer the options to 'write' method from the popup form
Steps to reproduce:
1. Create custom model to add a product quantity on hand(readonly) field on stock.move
2. Show this field on Warehouse>All operations>Create a Transfer> Create: Internal Moves
3. Add a Internal Move, then open it again, the quantity on hand field's value show 0. But change the product, the value is correct.
These onchanges were needless since it was already done by the
BufferedDataSet when we use alter_ids to add/remove ids/virtual ids from
the recordset.
The onchanges this commit remove were introduced with 6b907bb4d in
juliet 2012 whilst the onchange in the BufferedDataSet when using
dataset alter_ids was with dd747c096 in october 2012.
closes#8273fixes#7595
opw-644706
When a selection field with widget="radio" is False, the form view display the previews value for this field.
1 - Create a selection field (ex: [("1", "1"), ("2", "2")]), and display it on a form vue.
2 - Go to the form view (all the record have False value for this field).
3 - Change the value of this field for one record.
4 - In readonly mode, all other records now wrongly display this value (still False in DB or when "edit").
#opw-652002
The behavior of the datetime widget was to focus in the field every time a date
is chosen. This causes an issue if the datetime widget is called from an
editable list. Indeed, the list editable will consider that the value has been
set, and therefore the value will not be changed anymore if the user choses
another date.
The new behavior is to put the focus only when the date picker is hidden,
therefore the editable list will consider the value set only when the selection
is done.
opw-644062
Fixes#7463
Don't retrieve the binary contents just to display the size, but pass context
with bin_size=True instead
Always pass filename in download link
Combination of patches from the bug report from Enrico Ganzaroli, Cedric Le
Brouster and Holger Brunn
Fixes#4899, lp:1167429
To distinguish two ir.attachment 'File Content', we base it on the file
size (this I imagine is for efficiency).
This is done by setting bin_size in the context. Doing this, the
returned db_datas field will be the file size of the converted to base64
content (if no filestore).
But this size is returned in string format, so "get_nice_size" (in
openerp/osv/fields.py) which gets this size calculates the length of the
string. e.g: if the size is '2142' get_nice_size will return 4.
This fix solves this by converting the string to an integer, thus
unifying it with the filestore case (where we use os.path.getsize which
return an integer).
Also, the field presenting the issue (FieldBinaryFile) has been changed
so it is always updated even if the size is the same (as it was already
done by 3632949 for FieldBinaryImage widget).
closes#7223
opw-643071
This fix gives the domain to the "See selection" view opened from a
FieldCharDomain.
In Odoo 8.0, this widget is available at two places:
- mass_mailing: Marketing > Mass Mailing | Mass Mailing > (any
newsletter) > "See selection".
- gamification: Settings > Gamification Tools > Challenge > (any
challenge) > "See selection".
With this fix the "Selected records" view display selected records.
closes#6463
opw-633201
The onchange handler is doing a weak comparison between the values received from
the onchange() method and the current field value, which leads to a falsy value
such as "0000" being treated as equal to False.
This patches changes the operator to enforce non-coercive equality.
Fixes#6405
If a onchange is set on a binary field, the name of the file (filename attribute
defined in the view) is still the name of the previous file.
Fixes#2427, opw 617109
When setting a value to a field binary, a char field can be set as 'filename'
that needs to be recomputed to specify the new file name.
Before new api, the _internal_set_value method would trigger a onchange but it's
no longer the case now (so onchange on filename field was no longer executed).
Instead, manually set the value using set_value method which do trigger the
onchange.
Fixes#2427, opw 617109
Currently, the view_form search_count doesn't propagate the context, so when
searching on a translated field, the count can be different than the one we
would expect and get with a search in a current language different than en_US.
opw-628792 opw-630212 closes#5825
The sequence for new items in some models is simply set to a constant 10.
Hence if 3 items had after reordering sequences 10, 11 and 12. If a new item is
added, it would get after saving at the second position.
This fix set the sequence of a new item to the maximum+1 or minimum-1 sequence
of current items sequences (max if tree has editable="bottom", min if tree has
editable="top").
opw-627830
This temporary patch was used to simulate the presence of a
`display_name` field in all models. It is not needed anymore
as of version 8.0, which comes with the actual magic to make
`display_name` work everywhere.
Text fields, or char fields having widget="text",
were not sized correctly when the field was not
visible by default, ans was set visible thanks
to attrs and other fields values.
opw-629394
The priority widget did not handle the readonly concept
It was therefore possible to set the priority of
an issue (for instance) even if the field was marked
as readonly.
opw-628960
When accessing an existing record in form mode directly (enter the url or refresh a page), the daterecord has not been initialized yet. This means that the value of actual_mode will be set to 'edit' before loading the current record (method _actualize_mode() called from do_show()).
This was problematic for one2many fields that we loaded in edit mode, showing add/delete icons/buttons in readonly views. (opw 607910)
Backport of 7ec7f1ba40 for 7.0 and saas<6. (opw 627885)
Without this, if the user creates a second line (or more) with another search query and presses tab (or clicks somewhere else) quickly, it will take the previous search result instead of the new one because the new one did not occur yet.
With this fix, if the search did not have time to process, the Create a product modal appears, just like it already did for the same behavior on the first line.
Fixes 620679.
The onchange() on new records processes fields in non-predictable order. This
is problematic when onchange methods are designed to be applied after each
other. The expected order is presumed to be the one of the fields in the view.
In order to implement this behavior, the JS client invokes method onchange()
with the list of fields (in view order) instead of False. The server then uses
that order for evaluating the onchange methods.
This fixes#4897.
This reverts rev. 9f9e7ef0e1
As explained in 9f9e7ef0e1,
if a field "lang" is present in the view, clicking in any action item
in the more menu leaded for the action title to be translated
in the lang value of the form, such as in the partner form.
9f9e7ef0e1 fixed the issue,
but has as side-effect to not update correctly the active* keys.
So, if "active_id" was used in the context of the action button,
and the active_id was set in the dataset context, for example
because you come from another form, trough another action button
(For instance, Customers > Opportunities > Logged Calls),
the active_id was not updated with the current id of the record.
opw-620293
opw-617321
fixes#3462
In cases where data is directly given to the saveas_ajax controller,
the filename was not correctly set, as no read method was performed.
(The read call is useless as the data is already avaiable in such a case)
In such cases, the filename must be given in advance
opw-626707
This rev. reverts 91911159f5
The above rev. was a good idea, except that internal_set_value expects the raw value, while the records attributes can be tuples(for instance, many2one are tuple(id, name) or list of command(one2many, many2many).
set_value must be use here, as all fields (js) override set_value in order to handle their value repr (for instance, many2one fields handle the tuple (id,name).
Besides, avoiding the re-render provides a huge performance improvment, as rerendering fields can lead to xmlrpc calls (for instance, re-rendering a many2one field implies calling the name_get method)
opw-620111
opw-622108