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
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
Christophe Matthieu