This is not only dangerous but also
completely inconsistent with the other
db management screens. It also represents
little improvement in terms of usability
for first-time users, since the password
is now mentioned on the comment just above
the field.
bzr revid: odo@openerp.com-20130318155618-z9s2izahnv1j2no6
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
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
Christophe Matthieu