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 `bootstrap` flag is only needed for modules that
modify the login screen or DB manager, as these run
in a special bootstrap environment. Loading
database-specific translations requires to be logged
in.
bzr revid: odo@openerp.com-20130305173811-ab52c1x7l00zpgj1
My understanding is that EnumRegKey will index (the last argument)
the given registry path. When nothing is found, it sets the first
argument to the empty string. Only if the given path is wrong an
error is generated. So we have to go to the DoInstallPostgreSQL
label.
bzr revid: vmt@openerp.com-20130305110253-tu0t240liupxtchj
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
It is the call to upload_report() that triggers the registration
of the new reports in the system, as report services.
Unfortunately the `header` property of the report is cached in
the report service and taken from its value at
registration time. So that value *must* be written before
calling upload_report().
Also force the `Corporate Header` to be checked by default
as this is what users want in most cases, and forgetting
it at report creation makes it very hard to set afterwards,
as it is cached in the service.
Updated plugin binary as well.
bzr revid: odo@openerp.com-20130304173125-zky8rtdye64bep07
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
The setting/clearing of the tracking were not done
consistently, causing log messages that appeared
to come from one database while coming from another
one or none at all.
The tracker is now set at the earliest points
of request handling as possible:
- in web, when creating WebRequests (dbname, uid)
- at RPC dispatching in server (uid)
- at cron job acquisition in CronWorker (dbname)
- at Registry acquisition in RegistryManager (dbname)
The tracker is cleared at the very entrance of
the request in the WSGI `application`, ensuring
that no logging is produced with an obsolete
db name. (It cannot be cleared at the end of
the request handling because the werkzeug
wrapper outputs more logging afterwards)
bzr revid: odo@openerp.com-20130301182510-1fqo9o8di0jw95b5
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
Vo Minh Thu
Xavier Morel
Fabien Meghazi
Quentin (OpenERP)
Thibault Delavallée
Launchpad Translations on behalf of openerp
Olivier Dony
Cedric Snauwaert
Chris Biersbach
Xavier ALT
Stephane Wirtel
Fabien Pinckaers