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
In the search input, the result of filtered search with an arrow was
placed under the currently selected arrow.
Hence if we get to another arrow filter before the result is received,
the result is added under the wrong arrow.
This fix adds the result under the right arrow.
closes#6442
opw-632519
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
This fix adds the toJSON() method to datetime.datetime,
so domain expressions can use datetime values directly,
without having to compute the stringified version
with convoluted strftime() and timezone calculations.
The datetime results are sent down to the JSON-RPC
level where the JSON.stringify() serialization will
convert them to UTC string, to be deserialized
properly as UTC datetime values on the server side.
Thanks to this we can use the browser's local midnight
timestamp in a filter expression, for example like this:
`datetime.datetime.combine(context_today(), datetime.time(0,0,0))`
and get the expected result regardless of the user/browser's
timezone.
related to issue #2972 and pull request #2914 and #6229
(Next commit will fix them)
opw-621282
When a many2one field of a searchview was selected
by default, through a default_*_id within the context,
the many2one value name wasn't translated.
e.g. with Spanish loaded (and l10n_multilang installed),
translate a project.project name in Spanish.
Then, while being in Spanish, in the project.project kanban,
click on the Tasks link of a project (tareas),
then, notice the value of the project name in the
search bar.
opw-632818
Currently (since commit e6a2d222d6), the domain of a search view field tag
is dropped.
This previous change was done since some of these domains refers to a
field not available in the javascript.
This fix drop the domain only if it can't be evaluated in the javascript
side.
opw-632030
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
When opening a task through a modal, like
when opening the task field of an issue while
being in edit mode, the priority stars
had not the same design than in the
regular task form.
opw-633426
Create a new stylesheet for IE9 and less custom css.
The issue #6198 and #6201 is present in IE9 since a div with height 100% inside
a table-cell (i.e: td tag) element only take the minimum height possible for the
content.
For issue #6198: in IE9 a kanban tile could not be moved to an empty kanban,
this fix sets a minimum height for a empty column (80px, the size of two empty
tiles) so now a tile can be moved in the 80px in the top of the column.
For issue #6201: graphs took the minimum height in IE9, this fix set a fixed
height to improve the situation.
For issue #6200: in IE9, the list view could wrongly not go the next line
even if its width is 100%. For the given case, the display CSS property of
these listview is set to value "block".
opw-632415 opw-632417 opw-632416
Do not check float_is_zero for float fields with
digits specifically set to 0, it means
the rounding precision is infintie for those ones,
and tmp === val is enough.
Apparently, browsers decide how they want to style readonly inputs,
and it seems like Firefox is greying them out while Chrome doesn't.
We use an opacity: 0.5 rule to grey them out ourselves in Chrome,
but in Firefox they are not dark enough to read easily because of
the double greying. I checked with the designers but they don't
have any better fix for that.
On a line write in a account.move.line tree view, the on_write return all the
sibling move lines of the written move line. The lines are then displayed even
if they do not match the current search domain.
This fix adds the context on the given on_write callback request, and in
on_create_write use a on_write_domain in this context to filter the returned ids.
fixes#3161, closes#5727
opw-630093
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.
This patch removes the asynchronous code that was
still used to open the autocompletion drawer.
Even with the setTimeout delay forced to 0, the
asynchronous handling meant the final ENTER
keyUp event could be processed before the opening
of the autocompletion drawer related to the last
key pressed. This would trigger the search with
the search string of the previous autocompletion
popup, missing the last few keys.
Also handle ENTER at keyDown, because in some
rare cases a barcode scanner may emit only
the keyDown event for ENTER, without the
corresponding keyUp, causing a merge of two
successive scanned barcodes.
Based on many tests conducted with different
barcode scanners, the only thing that
is guaranteed is the correct order of the keyPress
events for all regular characters, and the
fact that the ENTER keyDown and/or keyUp will
always be sent after them.
All other events can be mixed or simply missing
if you make a rapid succession of scans, especially
if done with a long series of barcodes.
Scanners tested (with 1ms data transmission delay):
- Honeywell Eclipse MS5145
- Dacomex Slim 50mm CCD scanner
The menu was not present in 8.0 when going back from the mass mailing email
composer to the backend. This fix adds the current action id as a return_action
query string parameter and return to the correct action.
fixes#5591
opw-629526
This patch hopefully solves an annoying issue with the search view:
when the user types really fast (or uses a barcode scanner for example),
the resulting search string was (sometimes) missing the last few
characters. I'm unclear on the exact reason why it happens. From the
code, I can only guess that it happens because the scanner use a TAB
key instead of ENTER (TAB is handled in keydown event, ENTER in keyup),
or that the key events aren't in a correct order (if the user press a
key A, then press ENTER, then release ENTER, then release A, it results
in an empty key).
Anyway, the way this patch probably solves the issue is by using the
keypress event for triggering the search view. I hope that in every
case, the keypress event are correctly ordered. It leads to some code
I'm not really proud of this patch, but the key event handling are
quite messy. Also, I need to handle the search string also when the
keyup event is fired, because it might change the search (for example
backspace trigger a keyup, but not a keypress).
This issue is related to
http://bugs.jqueryui.com/ticket/8656http://bugs.jqueryui.com/ticket/8749d693ce5324
When opening a form view, scrolling down,
and opening a many2one dropdown menu,
the dropdown menu wasn't directly under its input.
It could be really problematic when the menu was not even
visible on the current browser page (when you had to scroll down
a lot to access the many2one input).
The issue was resolved as soon as you opened the dropdown
menu a second time, and did not happen if you didn't scrolldown.
But, on initialization, the dropdown menu wasn't at the right position.
Fixes#5603
opw-629601
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
Rewrite relativedelta.__add__ based on dateutil 2.4.0
* completely remove any hint of supporting time deltas (could be
implemented in the future, but not currently asked for and lots of
code to implement)
* implement weekday support (ordinal only)
* probably better leapyear support
* remove relativedelta.__sub__ (only works between relativedeltas)
* add relativedelta.__neg__
fixes#5089
When providing an args of ``null`` (or ``undefined``) and a non-empty
kwargs, the kwargs would be removed/ignored.
While explicitly providing a null args is not necessary, it's perfectly
valid.
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)
When the number of records n and the limit l were such that n%l = 0
(e.g. 16 records total, 8 displayed per page), clicking on the
previous button on the first page, or on the next button on the
last page produced a bug because the total number of pages
computed for this edge case was incorrect.
27a48f8026 introduced the use of self.dataset
It appears it is not always defined.
Few lines above, self.getParent().dataset is used,
and looks to be always defined.
We therefore now use this dataset in order to get the context,
to correctly pass the current session language.
Closes#5416
This rev. reverts partially 1d76586a1b
This rev. is related to #3462
Regarding addons/web/controllers/main.py
---
name of model ir.actions.actions is not translated
it's the name of server actions, client actions and window actions
that are translated.
Meaning the name of the ir.actions.actions will always be in English,
even when passing the user language within the context.
Regarding addons/web/static/src/js/views.js
---
There is no reason to pass the field values within the context
of the /web/action/load call: The read methods of actions are
not overidden to use the field values. Besides, it pollutes
the context of the action, leading to unwanted behavior, such
as the translation of the action name within the lang available in the
fields of the form view (e.g. the partner form).
Initially, the field values added in the context has been added
within the rev. 542928adde
Indeed, sidebar_context (or sidebar_eval_context nowadays), contains
the field values, and the additional_context passed to /web/action/load
is an extension of this sidebar_context.
We are not sure the reasons why the sidebar_context was passed to the
/web/action/load, but we believe it was to pass the session/user context
containing the lang, timezone, and so on, not to pass the fields values.
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.
When having several databases in the login form (not monodb mode),
when switching from one database to another,
if the company logo was different,
the company logo could be the logo of the database you came from.
fixes#5291
opw-628131
When clicking on an element in a listview editable, the record_id
is not updated in the dataset, which means that when you switch to form
view, the list view does not display the last selected record.
Also, it should fix the issue solved by PR pull/2725
During the refactoring of the web client, the self.$el has been changed
from .openerp to body, so the notification was no more into the .openerp container.
Custom css (eg .highlight) was no more applicated.
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
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
If the list view had a default order,
for instance, default_order="create_date desc",
setting a groupby filter kept this default order
and the groupby list was therefore not ordered on the groupby field
In general, when setting a groupby filter on a list
we expect the list to be grouped by the groupby field
The reset of the orderby is done only when the list is not grouped
and a first groupby filter is applied.
The orderby is not reset when adding a new groupby,
when one was already applied.
It doesn't reset either when passing from 2 groupby clause to 1.
It doesn't reset either when passing from 1 groupby clause to none.
opw-627233
When converting a datetime field to date, using the widget date,
the date time value was just cropped, removing the hours,
therefore ignoring the user time zone.
For instance, if the user was in UTC + 1, for a date time 02/02/2015 00:30:00,
applying the widget date on this datetime had as result 02/01/2015,
due to the fact the UTC value of the datetime field was 02/01/2015 23:30:00
fixes#4420
opw-621281
This is related to rev. d17f22cde7
Compare float values using float_is_zeor only
if the key is 'value',
meaning the changed value is the actual value of the field,
not another variable of the field (widget, etc.)
For instance, changing the currency_info of a float field
using the monetary widget should not compare the old and new value using
float_is_zero (the values are not even floats).
opw-627166
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
If the variable was existing outside the context of the ``foreach``,
the value is copied at the end of the foreach into the global context.
Fix#4461 - Q74531 - Q71486 - Q71675
In case of an empty inline column, a Download link inviting the user to
click would still be rendered (erroring out if the user eventually
clicked on it)
fixes#3684
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
When setting a float field,
the web client rounds the value entered by the user
using the instance.web.round_decimals method.
Nevertheless, this is possible that this method returns unrounded float,
due to the float precision
For example, round_decimals(53.8, 2) returns 53.800000000000004
In order to compare this new float value to the old float value
and check the eventual change),
we need to check if the delta between the two is almost 0.
This is the goal of the float_is_zero method introduced during this rev.
which is comparable to the float_is_zero method
already available in the openerp server, in openerp.tools.
Float values compared using the simple === operator
instead of this float_is_zero method
will be regarded as different in some cases,
according to the float value and the precision
And the value of the field will be regarded as changed,
which can lead to unwanted triggers of onchanges.
opw-626635
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Some .xml,.csv,.po,.woff,.ttf,.png,.eot,.svg had perm 755, provocating
'executable-not-elf-or-script' lintian warning for Debian packaging.
Set permission to 644 for those files.
Also remove unnecessary executable permissions on some .py:
-addons/l10n_fr_hr_payroll/report/fiche_paye.py
-addons/l10n_ro/res_partner.py
-addons/l10n_ro/__openerp__.py
-addons/l10n_ro/__init__.py
-addons/l10n_do/__openerp__.py
-addons/l10n_do/__init__.py
Use the local copy of those libraries instead of fetching them at runtime.
This fix was required for Debian packaging. It fixes the
privacy-breach-may-use-debian-package lintian error.
courtesy of mva. This adds the weekday function to date objects in
pyeval. This will be useful for adding better filters (such as this
week) in the searchview.
- let the user choose between the pg_dump custom format or the zip format including the filestore
- use file objects to allow dumps larger than memory
- postgres subprocess invocation is now clean and thread-safe, we dont touch the local process environ anymore
- add a manifest to the zip dump format with version information about odoo, postgres (pg_dump doesnt output it) and modules
Christophe Matthieu
Nicolas Lempereur
andreparames
Denis Ledoux
Luc De Meyer
Martin Trigaux
Christophe Simonis
dhr-odoo
Cedric Snauwaert
David Monjoie
Olivier Dony
Julien Laloux
Géry Debongnie
Nicolas Martinelli
Xavier Morel
Aaron Bohy
Jeremy Kersten
Raphael Collet
kevin wang
Adrien Peiffer
Simon Lejeune
Antony Lesuisse