Implementation of invisibles in search view altered handling of search
inputs: their parent may not be the searchview anymore (usually is a
instance.web.search.Group). GroupbyGroup assumed parent was view and
was actually unused until
xmo@openerp.com-20130307124222-1ypzfopbktxmad4z, which exposed the
incorrect underlying assumption.
Make GroupbyGroup access its view when it wants its view, not its
parent.
bzr revid: xmo@openerp.com-20130312092824-z7sh4h3ityo4g00v
The server only supports the ar_SY variant of arabic, so this is the
one and only locale arabic speakers can currently select. According to
Ahmad Khayyat:
> The [ar-SY datejs localization] uses uncommon month names, which are
> hard to recognize. The more common month names should be used
> instead.
This could be reverted if more arabic locales are made available in
the server, in order to limit deviations from the upstream package.
lp bug: https://launchpad.net/bugs/1151704 fixed
bzr revid: xmo@openerp.com-20130308080020-6q370e2kmrk2xk2w
Before the valpocalypse, filter contexts were "literal" (parsed
objects) when reaching the search view, and `.attrs.context.group_by`
would return the right thing (namely the group_by attribute of the
context object).
After the valpocalypse, contexts & domains on view fields (and
filters) are not evaluated on the Python side anymore and reach view
objects as strings, the access chain above thus always returns a falsy
value (undefined) as strings don't have a .group_by.
Fix FilterGroup to correctly parse filter's @context before trying to
see if it has a group_by.
lp bug: https://launchpad.net/bugs/1116432 fixed
bzr revid: xmo@openerp.com-20130307124222-1ypzfopbktxmad4z
The big issue was the hooking on the closest ui-dialog's scroll event:
if an m2o in a dialog (e.g. wizard-type situations) toggled state from
editable to readonly (workflow action of some sort), the event hook
would remain, and call .$input.autocomplete("widget") which would blow
up because the autocompletion widget hasn't been re-initialized.
Take care to fully unbind all events during the reload process to
avoid this issue (and potentially other such as duplicate bindings and
the like).
lp bug: https://launchpad.net/bugs/1146321 fixed
bzr revid: xmo@openerp.com-20130306145527-sssv7ocfvqxgv896
xmo@openerp.com-20130305093619-s1e5fbl80r7qnk5l added zIndex on wrong
element of search view (view itself instead of just the autocompletion
drop-down) leading to the search view text field being visible over
the "more" section of the menu.
Move zIndex setting to the right place (on the missing
`autocomplete('widget')` indirection, and on open as jquery ui
autocomplete apparently decides to reset the dropdown's z-index each
time it is open)
bzr revid: xmo@openerp.com-20130306110051-1wfhxaylsn71skjp
Because the Add/Create button is global, it's not really possible to
know *where* to create the new record, and the current design can't
really deal with a record being edited outside of all groups.
An option might be to create a dedicated empty group for that, but the
cost/benefit is high and the UI would probably be odd.
lp bug: https://launchpad.net/bugs/1098205 fixed
bzr revid: xmo@openerp.com-20130306102136-2ms7llbt4swka92k
The search view's completion list should be in front of the search
view's drawer, which itself should (probably) be on top of the graph
view's "action" dropdown.
The graph view's dropdown itself needs a z-index > 0 to be in front of
the graph itself, otherwise it is inactive and unusable: it's visible
through the graph but not activable.
bzr revid: xmo@openerp.com-20130305093619-s1e5fbl80r7qnk5l
m2m lists inherit (from listview/view) the handling of access rights
attributes (e.g. @create, @delete) in which the access rights to the
related model are those checked for the view. This is generally true,
but *not* for m2ms: even if a user has no creation rights to the
related model, he can still create a *relation* between the current
and related models.
The m2m access rights are really governed by the *current* (source)
model, in which case the user won't get to see an "editable" view of
the m2m in the first place.
So just override is_action_enabled to disable it in m2ms.
bzr revid: xmo@openerp.com-20130305091956-zn6qtuo4tl0vh3bs
* really call initial get_selection() after binding 'change:selection'
overwise no value are assigned to internal selection list - resulting
to an empty statusbar when field type is 'selection'
bzr revid: xal@openerp.com-20130304230253-0e959r9sintwsd98
This leads to any subsequent view overwriting the current user's lang
or timezone with the one active when the filter was created,
generating dismay and discontent (e.g. part of the user interface
switching from spanish to english or english to german, depending on
the respective settings of the current user and the filter creator —
at time of filter creation).
bzr revid: xmo@openerp.com-20130304101414-mm6ai1dkltd7ard5
Xavier Morel