More consistent behaviour. Was not able to access unauthorized data (retrieving data on x2m field would trigger security rules) but make sure it raises an exception instead of silently retrieve no data.
Move construct domain inside if clause as no needed before
bzr revid: mat@openerp.com-20131205113254-j3j4bb0p6ed23oht
* ensure users correctly get a 403 forbidden from a failed
_authenticate
* as far as we can tell, NotFound is one of the few things
_authenticate does *not* throw. Catch all exceptions anyway.
* replace default _handle_500, _handle_403 and _handle_404 by single
generic handler since all they did was re-raise the exception anyway
bzr revid: xmo@openerp.com-20131126110519-0yjh01ubrulpzlmn
user's language: old (untranslated) -> new (translated)
other language: old (untranslated) -> old (translated)
This allows to have coherent behaviour if copy() method is overwritten to change the text (usually applying _('%s (copy)')). The current user will see the translated terms with modification while the translations are kept for others (and need to be updated).
We prefer keeping slightly irrelevant translations (without translated version of '%s (copy)') for other languages than losing it.
bzr revid: mat@openerp.com-20131125110736-d6iygeq8om5y4fkz
The browse_record prefetching algorithm attempts to
load data for all known records from the requested
model (i.e. all IDs present in the browse cache),
regardless of how indirectly/remotely they were
referenced. An indirect parent record may therefore
be prefetched along with its directly browsed children,
possibly crossing company boundaries involuntarily.
This patch implements a fallback mechanism when
the prefetching failed due to what looks like an
ACL restriction. This being a fuzzy concept at the
moment, it does its best to only catch a restricted
set of exceptions, and retry loading the data for
the directly requested ID only.
This may cause a small performance penalty in case
of real errors (with some spurious logging too),
but should only be triggered in very few cases.
The downside when this happens is that the prefetching for that
model gets effectively disabled, requiring multiple
SQL queries for further access to the data of
the other directly browsed records.
This EAFP approach seems safer and faster than
a LBYL technique where we would have to filter
all indirect m2o references according to ACLs
before allowing them to enter the cache.
lp bug: https://launchpad.net/bugs/1238042 fixed
lp bug: https://launchpad.net/bugs/1212429 fixed
bzr revid: odo@openerp.com-20131120100627-031fljyf4ckprc9b
> many2one --> mettre <br/> si multi-line, html escape le reste (ex:
> adresse sur un event, on a du mettre dans un <pre> mais ce n'est pas
> bien)
> text --> mettre <br/> si multi-line, html escape le reste (ex:
> description d'un produit, à droite)
> char --> normalement pas de multi-line
> fields.binary --> t-field on image field ne semble pas fonctionner
> en écriture (la photo d'une fiche produit)
(validates that the binary field's content is image data by opening it
with PIL, then generates an <img> tag)
TODO:
> fields.float --> utiliser le digits pour formatter les decimals
> correctement (ex: prix d'un produit, à deux décimales)
> On aura aussi besoin d'un widget="currency", un peu comme dans la
> vue form du client web.
bzr revid: xmo@openerp.com-20130926133850-ab14h241q878jbom
When a new inheriting view is imported during a module
installation, it is validated thanks to the _constraints
on the ir.ui.view model. However the validation uses
a rather convoluted system for validating the whole
view tree at once (root view + all inherited changes)
while only taking into account the views that belong
to modules that are currently loaded.
This complicated system is necessary to be able to
operate on-the-fly at any point during the registry
loading/initialization.
Now because _constraints are checked during create()
this particular validation happens *before* the
external ID (ir.model.data entry) of that new view
can be created (it obviously needs to wait until
the view record is inserted). As a consequence the
view validation cannot determine the module to
which that new view belongs, and was erroneously
ignoring it.
Changing the view filtering to also include views
that have triggered this check.
Manually created views are not check during registry
update.
bzr revid: chs@openerp.com-20130912141018-qmcyase8zqov9d01
Christophe Matthieu
Christophe Simonis
Denis Ledoux
Martin Trigaux
Xavier Morel
Olivier Dony
Thibault Delavallée
Fabien Pinckaers