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
Could happen when a worker thread is reused for another
database but does not go through all the dispatching levels,
e.g. for static resources served by werkzeug itself.
bzr revid: odo@openerp.com-20130301171616-joit5dvjx51ums1y
Evict record from BufferedDataSet cache as is done with button calls,
otherwise when caller reloads record (read) after having executed the
workflow action, it'll get the old one back from the BDS's cache.
bzr revid: xmo@openerp.com-20130301103543-jra87w2wm417tgyc
Could happen when a worker thread is reused for another
database but does not go through all the dispatching levels,
e.g. for static resources served by werkzeug itself.
bzr revid: odo@openerp.com-20130228173530-bs5pun9o09iobosi
The chrome cache bug seems to be gone with newer versions.
Moreover, the cutting edge features of the webkit developper tools
won't work if url changes upon reload.
bzr revid: fme@openerp.com-20130227114134-nlv7g5jjvvd037p2
When using the ``set_editable`` feature (context key) from filters
(togglable on/off), the list view would not correctly clean up
(destroy) the form when switching from editable with a started editor
(and form) to non-editable, leading to form fields (in this case m2o
fields being in an incorrect state and trying to query a non-started
autocompletion widget on every click anywhere blowing it up).
lp bug: https://launchpad.net/bugs/1117320 fixed
bzr revid: xmo@openerp.com-20130225135629-8k338gw0arsi6m6j
jquery-ui's date picker (at least in currently used version) lets
*some* (but not all) clicks go through. The date picker dialog is
added directly to the page body so capturing clicks in a parent widget
doesn't work, and these "stray" bubbling clicks will trigger the
global bus's "click" event.
Add a capturing (and stopPropagation-ing) of these clicks in our
wrapper to jquery-ui's datepicker to avoid the issue.
lp bug: https://launchpad.net/bugs/1095283 fixed
bzr revid: xmo@openerp.com-20130225110614-p7dmmjd41xdxescy
Launchpad Translations on behalf of openerp