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 parent records on objects of the _inherits.
Therefore, in order to make the trigger on the linked field works, we should
include all the _inherits values (fields that make the link to the parent
record) because they are created implicitly.
The write() method does not need this change, as any update of the parent
fields has to be explicit.
bzr revid: odo@openerp.com-20131209184718-wczdefzo9evc0cgc
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
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
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
This was apparently a long-standing issue due to a
strange handling of the _prefetch attribute on
columns: accessing a column would only trigger
the prefetching if its _prefetch attribute was
True, but the prefetching itself would also
prefetch columns that had _prefetch False.
We clearly want it the other way around, or
at least we want _prefetch to decide whether
a column is included in any given prefetching
pass. We can skip the prefetching pass when
the only field being accessed has _prefetch
False because it is likely the other fields
have already been prefetched separately.
This last subtlety should not make any
noticeable performance difference.
lp bug: https://launchpad.net/bugs/1177965 fixed
bzr revid: odo@openerp.com-20130620131057-v7s4qfqj976j3ufo
- res.partner must prevent creating loops in partner
hierarchies, and this can be done easily with an
extra _constraint using the ORM's builtin _check_recursion
- _check_recursion's implementation incorrectly
assumed that the provided 'ids' were unrelated
(not part of a common hierarchy).
- add tests for _check_recursion via extra
tests on res.partner structure
(explains why both patches are in the same
commit)
bzr revid: odo@openerp.com-20130415171732-aj3j2e2mycvzf4kp
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 where we can:
- in web client, 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-20130301120744-jfitcmze2jldecod
The case where no constraint existed at all was not working,
and after fixing it, the ORM started to re-create the same
constraints multiple times for some modules. This was for
models that are split within a module (such as res.users in
base, which is made of several small classes): all the
partial models were going through _auto_init instead
of only the final one - doing useless extra work.
Unfortunately establishing the FK happens before the
XML data files are loaded, so a number of FK and
NOT NULL constraints failed to apply due to missing
tables/records. base.sql had to be extended a bit
to cover these cases in a minimalist fashion
bzr revid: odo@openerp.com-20121217214645-av9n003yzterhujw
Loading time was mesured on the loading of a second database (identical to the
first one), i.e. by passing -d xx,yy on the command line, using cProfile. The
databases were installed with sale, mrp, and the crm.
The cProfile code is commited as part of this patch and should be removed (or
maybe guarded by some command-line flag) (just as the commenting-out of the
cron startup).
The patch was also applied on top of the trunk-simple-table-stats-vmt branch
which provides SQL queries counters.
Results indicate that the number of SQL queries are reduced from about 2100 to
27. Loading time is reduced from 1.3s to 0.26s (i.e. improved by 5).
Changes:
All calls to ir_model_fields to fetch manual (custom) fields are done in a
single call (prior to instanciate all models).
Checks for empty module descriptions are not done unless we are in init or
update mode. (The behavior was the opposite, which was probably a mistake).
Some calls to ir_translation, passing en_US because there was no lang in the
context, are not done anymore.
The improved time is also a result of a change in the decimal_precision module
where precision_get fetches all digits/applications instead of one at a time
(and thus implements its own caching instead of relying on
openerp.tools.ormache).
bzr revid: vmt@openerp.com-20121211105954-lwgs5js7yw3tzghs
expression.parse: refactored the main parsing loop, now using source and result stacks. Leaf elements are encapsulated into a specific object, allowing to delegate the join condition formation, working table management and table aliases generation to them. The parsing is now a simple loop taking a leaf, doing one action on it, and putting the result back to be analyzed or in the results. This allows to avoid having nested loops and uncontrolled results.
Other modifications :
- updated the generation of order_by to take into account the table now referred using aliases
- updated Query object to use the aliases
- fixed an outstanding bug about _order, now handled as order. This means that putting direct SQL into _order of models will not be supported anymore, because of the computing complexity now that we have multiple joins in queries. The branch holds the patch from Paulius Sladkevičius
- updated and added tests
- added a basic documentation for the freature
lp bug: https://launchpad.net/bugs/1070757 fixed
bzr revid: tde@openerp.com-20121210154652-6sab9usb38i7adlh