By default, on binary images read, the server returns the binary size
This is possible that two images have the exact same size
Therefore we trigger the change in case the image value hasn't changed
So the image is re-rendered correctly
As `_inherits` fields are now handled via `related`
fields (not stored, obviously), a new descriptor
`searchable` has been added to `fields_get()` result
to indicated if the field is searchable or not.
tooltip stuck visible should be removed on click + remove tooltip container except for modal in order to prevent them for staying visible in some rare occasion
function start, line 783, filters_ready waits for fields_view_get deferred to be resolved before calling prepare_filters, which prepare the view filters.
The thing is that, at line 416, if this.headless boolean is true, the searchview is marked as ready (by resolving the this.ready deferred), and the fields_view_get deferred will never be resolved, as it is resolved in the else case, where the this.headless boolean is false.
Therefore, in this.headless true case, this prevents the deferred $.when(this._super(), filters_ready) to be resolved, as the deferred filters_ready will never be resolved. Therefore, the deferred returned by the start function is never resolved, and the searchview will never be regarded as ready neither.
In views.js, the ViewManager is marked as ready when the deferred manager_ready = $.when(searchview_loaded, main_view_loaded, this.view_completely_inited) is resolved. In the this.headless true case, as the searchview is never marked as ready, the manager isn't neither.
This leaded to some issues, like the action buttons in form views being disabled on click, and never re-enabled once the action/wizard executed. See opw-610723
Due to the switch to Bootstrap 3.2 in this version, tooltip auto placement works erroneously (see https://github.com/twbs/bootstrap/issues/13897).
This is a workaround, waiting for a fix in Bootstrap assets.
(Closes#1341)
If an action unlink the current records (e.g. unreconcile on account.move.reconcile), trigger history_back to avoid errors when trying to reload inexistant record (opw 607883)
This is a partial backport of saas-4 code (rev c0db6ae, 162ad1c) and should not be forward ported.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
The goal is to ensure that HTTP requests
done while reloading the client (e.g. the
menu bar, etc.) do not use a deprecated
session context.
Also undo the previous fix from a0ee2b5
as it would cause other issues (e.g.
prevent setting the admin password/lang
when creating a new db using the db manager)
This logic does not belong in the business
methods of res.users.
When going up and wrapping around, the focus was on a hidden separator,
so hitting enter = stacktrace. Now, the focus goes on the last
selectable list item.-
Allow binding an optional `action_id` to filters.
The web client will try to identify the specific
action ID when saving new filters. If no contextual
action exists, the filter is saved globally for
the model.
This will automatically keep filters within their
original menu when there are several menus/actions
leading to a given list of documents.
In some cases the action_id will not match the
filter model, which should be fine (e.g. when opening
a many2one completion popup for model `foo` within
a menu of model `bar`).
It is also still be possible to have a filter apply
to all actions/menus for a given model by manually
deleting the action_id value in the filter
(e.g. via the Manage Filters debug menu).
When updating a filter the action_id value is ignored
so that old global filters will be gradually replaced
by new "local" filters.
Also added an _order to ensure stable ordering of the
filters.
Displaying the pagert in view group does not make sense as it's not updated when changing filter and every group (even if more than 80) is displayed in view group
The switch mode event was triggered even if the view was not actually switched
This leaded to inconsistencies, like adding the view in the breadcrumb history, while the switch did not happen
When you are on a form view, you click on a left/right arrow(on the top-right of the view) to pass to the next records. If you click on the widget to change the kanban_state, the widget will change the state of the previous record and not for the current because the record_id is not reset
Task #5009
This new autocomplete widget (the one used in the search bar) does not
do remote calls automatically, but on demand. In theory, it should lead
to a better user experience, not having the ui blocked every time long
remote calls are done.
It also has the benefits of bringing us one step closer to not
depending on jquery.ui. Bonus point: the code is quite short (< 200 loc
i believe)
An asset bundle is now versionned with the dates of the
ir.ui.views that compose it and also with the dates of
the files and ir.attachments linked inside the bundle.
This new behavior is reflected in the bundle's lru cache
managment.
When attempting to parse client date, value is not always a string.
We force the toString when adding the leading 0, as the replace method is for string
[FIX] view_list: Add context propagation for m2m list view
If the _rec_name field of a model is translatable, the value was not translated when displayed in a list view through a many2many field (e.g. server_action_ids on base.action.rule).
- output "error" if any qunit tests failed
- failed js tests are logged as errors
- when running phantomjs considere empty waiting condition or initialisation code as "true"
- lint phantomtest.js file
When searching for a record in a m2o field, if we click on 'search more' we loose the focus on the field and select the first suggestion (which triggers potential on_change). This prevents the selection for this case.
When adding an item to the editable list, the focused field was no longer the first visible field
This is related to revision 4a508885ac
visible_columns list is not ordered
the code handling the keydown events was moved, but the variable this
was not adjusted accordingly, resulting in a broken navigation.
It is now possible to press LEFT and RIGHT again to move the focus
between facets.
Assuming access rights are correctly configured, this allows providing
downloads for any attachment type, not just to display images via
/website/image.
TODO: unify attachment querying, we've got stuff over both web/ and website/
In editable list, on keypress enter, the _next method is called, saving the current line and starting the edition of the next one
The _next is triggered before the date(time) field change event, and, therefore, the saved value of the date(time) field is the old one
Create a deserialize_sort method and add a set_sort method to
datasets. The set_sort method is useful to avoid duplicating code
in lists and kanban views (to set the initial default order)
List views can now be sorted by default with a simple keyword 'order'.
For example
...
<field name="arch" type="xml">
<tree string="Product Variants" order="name">
<field name="name"/>
...
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
the jquery method length() compute the height of its element, even if
it is diplay:none. But in our case, we want the offset to be zero if
there is no visible view_manager_header. (for example, general settings
in settings menu)
in drawer, advanced search, it can happen that the form extends out
of the drawer. Overflow:auto at least allows the user to interact
properly with the form.
due to the way breadcrumbs work, the method adjust_view_top was
not called at the correct time. This had the unfortunate consequence
that the main view was on top of the header.
This fix is related to a37bad205b
This previous fix did solved the issue of its purpose, but had a side effect for actions using these active* params, e.g. search views
For instance, Go to Project > Projects, click on any project, you are than redirected to tasks/issues of this project
If you reload the page, an error pops up, complaining that active_id cannot be found
the height of the oe_view_manager_header is variable, and the top can't
be positioned correctly with pure css without a lot of work, so this
commit adds a touch of javascript to make sure that the view is
correctly positioned.
This commit is related to 8d49639933 and b88755c431
When hitting buttons of type object, the active_model and active_id(s) were kept, and, therefore, when calling a feature using the active* args, this feature used the active* args from the previous action.
Nevertheless, concerning wizards, the active* args should be indeed the active* args of the previous action, as wizards expects to have the active* args from the previous action. Thus, we reset these active* args only when this is not a wizard (target === 'current')
For example, from a sales order, hit the 'view invoice' button, and on the invoice, hit the 'send by email' button: The active_id in the send by email wizard were the id of the sale order, not of the invoice
* oe_searchview_custom has been split in oe_searchview_custom and
oe_searchview_filter: a test need to take that into account
* in adjust_top, the parent might not have a $ method.
* separate the css class oe_searchview_custom into oe_searchview_custom
and oe_searchview_savefilter to be able to style them independently
* by default, the drawer has display:none
* fix a bug occuring when the user removed a custom filter (it hid the
remaining filters)
the header height is not fixed, it can change when the breadcrumbs
start a new line, or when there is only one view type (for ex, in most
reporting views). So, the top value of the view_manager_body has to be
adjusted accordingly.
the mail menu is a client action, so not subject to the same template
as regular views. so, it had to be patched to properly scroll like
other views (meaning: the 'header', left menu and top menu are fixed)
Also, changes the width of the searchbbar into a min-width css property,
to allow it to grow more. The reason is that we don't want the searchbox
to take two lines (or more), which will force the view_manager_header to be
higher, and which will cause slight issues with the scrollbar (absolutely
positioned)
(1) it seems that position:relative behaviour is undefined in a td,
so it has been moved to the div below oe_application
(2) the left menu bar can now scroll vertically if necessary.
when a view_manager is contained inside another, the
css rule for defining a scrollable zone (with position:absolute)
was also applied to the inside view manager.
correct a few problems introduced by the change to the scrolling area.
Note: body is in overflow:auto to allow scrolling when there is no view
manager (for example, client action)
Now, only the main view is supposed to scroll (the part below the
header with the view selector). The left menu, top bar and header
are supposed to stay fixed. This is done by carefully using
position:relative and absolute. However, this is likely to
introduce some (many?) issues, perhaps with tooltips position and
such. The bug hunt is on!
add a div parent to oe_view_manager_body, and move the searchview
drawer inside oe_view_manager_body. This is in preparation to the
goal of making the oe_view_manager_body div scrollable
to accomodate the fact that the searchview has been changed.
Two changes need to be accounted:
(1) the drawer html structure has changed (oe_selected class is
replaced by badge, some li tags are replaced by spans, ...) and
(2) the CustomFilters has been split into CustomReports and
SaveFilter, so there is an extra filter in the drawer inputs.
Also, the searchview need a parent to react to the switch_mode event,
so the tests add a fake parent to the view in make_search_view
after some thought, the extra method insert was not really necessary.
It was at first a way to force the user to give two nodes to determine
where the searchview and the drawer were to be inserted. However,
the second node can be omitted, a perfectly reasonable default is
to append the drawer just after the searchview.
Then, the role of insert is exactly the same as appendTo, so it makes
sense to override appendTo and remove insert. Simpler, and the job is done.
this commit splits the widget CustomFilters in two widgets:
CustomReports and SaveFilter. CustomReports is the widget
displaying the list of reports, and SaveFilter obviously is the
Save Current Filter widget.
The goal was to put the custom reports in the first column and the
Save Current Filter form in the second.
Before, the searchview and the searchview drawer had to be instantiated by
the user and appended separately to their correct place. Now, the
searchview is responsible for creating/destroying the drawer, and the
user is responsible for correctly using the insert method with
the node where the searchview/drawer are to be inserted.
the searchview has been splitted in two widgets: SearchView and
SearchViewDrawer. They are dependent of each other, so a drawer
has to be created for each searchview. This was not the case in
some form views (inline, created by a wizard).
the drawer wasn't closed when switching views, which might be a
problem when the user switches to a form view. Also, renames the
variable 'searchview_drawer' to 'drawer'.
incomplete work. So far, the search view widget has been split in
two widgets: SearchView and SearchViewDrawer. The SearchViewDrawer
has been inserted inline, and some preliminary work has been done
to improve the layout.
Fix bug https://bugs.launchpad.net/openerp-web/+bug/1279885 :
Many2many fields in Tree views will not get translated.
If you check the context for a name_get of a m2m field, it is passed as
None.
Add context propagation to m2m fields in list views.
Fix translation issues when viewing a a many2many field in a Tree view.
Denis Ledoux
Cedric Snauwaert
Thibault Delavallée
Raphael Collet
Christophe Simonis
Olivier Dony
Vidhin Mehta
Martin Trigaux
Anaël Closson
Richard Mathot
rlu-odoo
Xavier Morel
sle-odoo
Christophe Matthieu
ssh-odoo
Fabien Meghazi
Géry Debongnie
Antony Lesuisse
tfossoul
Martin Trigaux
Jacques-Etienne Baudoux
Mehul Mehta
Denis Ledoux
Mohammed Shekha
etenesaca
Pariket Trivedi
Sandy Carter
Launchpad Translations on behalf of openerp
Christophe Simonis
Mahendra Barad
Vidhin Mehta (OpenERP)
Mohammed Shekha
Gery Debongnie