When a varchar column has a dependence on a view, we cannot change the size in-place,
we need to manually re-create the column with the correct type.
bzr revid: chs@openerp.com-20140217182045-qor70r3gb0fch2ki
Sorting was done using a search on ids that where found in a custom SQL field,
only 1 record among aggregated records with same groupby value was used
when using search for ordering, resulting data ordered on
max(aggregated_data).field_value instead of sum(aggregated_data.field_value).
lp bug: https://launchpad.net/bugs/1060086 fixed
bzr revid: acl@openerp.com-20140217172926-ka2fw8t2l3cqi7h3
Historically, we used a copy+rename technique during
table upgrades to alter varchar columns sizes.
This was only necessary to permit downsizing
columns, which we do not want to do anymore (it is
too dangerous, so has to be done explicitly when
required).
Switching to a pure ALTER COLUMN TYPE is simpler
and also much faster for large tables.
Also fixed the inappropriate name used for
temporary columns during column type casting
(which *does* require the copy+rename technique).
bzr revid: odo@openerp.com-20140217164239-0iou3dsiea3foabb
- removing the need of the use of search when groupby is set on a relation
field.
- creation and use of dedicated helper method to compute the orderby clause
for easier reading
bzr revid: acl@openerp.com-20140217140144-2rm3o00g76tyhqxn
Sorting was done using a search on ids that where found in a custom SQL field,
only 1 record among aggregated records with same groupby value was used
when using search for ordering, resulting data ordered on
max(aggregated_data).field_value instead of sum(aggregated_data.field_value).
lp bug: https://launchpad.net/bugs/106086 fixed
bzr revid: acl@openerp.com-20140203125854-ypi0bu0lbhatg9b1
Issue introduced in
revid:chm@openerp.com-20130828161130-641xsmbr8xm53xjx: context of a
fields_view_get can provide a *_view_ref name (e.g. tree_view_ref),
whose value is an xid for the view to use (can be used to specify a
view instead of providing a view_id, mostly for embedded views where
there is no way to provide a view_id).
The view_ref being an external id, it must be dotted. Historically,
undotted xids were silently ignored and the system just skipped to
getting the default view for the model (lowest priority view where
inherit_id is null).
In revid:odo@openerp.com-20130821122955-8c9z0mi8cu48rne3 this behavior
was altered to emit a warning when ignoring a malformed view_ref. When
this change was merged into trunk-website-al, the conditional
(view_ref and '.' in view_ref) was split without consideration for the
semantics change: a syntactically invalid view_ref would fall off the
first branch (view_ref) instead of taking the second one (not
view_ref), the code would not fetch the default view for the model and
would instead generate one (through _get_default_%(viewtype)s_view).
However, closer reading reveals the code was already broken in a
specific case of a syntactically valid but unknown xid (view_id
wouldn't get assigned in the first branch, but the code would not take
the second one, resulting yet again in a view generation even if the
database contains a valid view for the model and type).
Fixed by reintroducing explicit second check on view_id, instead of
merely conditional alternative.
bzr revid: xmo@openerp.com-20140123075742-603n2zthqhxee07y
Save a few time by not not trying to apply ir.rule for superuser, that will
anyway be skipped within ir.rule's ``_compute_domain`` method.
bzr revid: xal@openerp.com-20131210140330-oui4oy8pez12xkxv
The create() method implicitly creates record on objects of the _inherits.
Therefore, in order to make the trigger on linked field works, we should
include all the _inherits values (field that makes the link to the rel
record) because they are created implicitly.
bzr revid: cto@openerp.com-20131209154857-788f94w0kh6ef5pp
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