check: verify the permissions even when no ids are passed (skipped permission checking for create)
create: verify has the write access on the related model (instead of create, was not checked anyway)
function field: execute the write in fnct_inv as superuser (was impossible to have creation without write access)
bzr revid: mat@openerp.com-20131030084408-t857gl7d4lkbrj5p
check: verify the permissions even when no ids are passed (skipped permission checking for create)
create: verify has the write access on the related model (instead of create, was not checked anyway)
function field: execute the write in fnct_inv as superuser (was impossible to have creation without write access)
bzr revid: mat@openerp.com-20131029171420-x87wu7ph8ej7mtro
This should have no effect because when the first `if`
is entered a new registry is instantiated with
the default value for base_cache_signaling_sequence
set to 1, preventing entering the next `if` even
without `elif`.
bzr revid: odo@openerp.com-20131011123914-7zuvd9mch21yxgj8
When the sequence value is 1 it means that either:
- the registry was just instantiated, so there is no
reason to reload it immediately, the real checks will
start at next request
- the db was just created with new sequences set to 1,
so there has been no change to reload
In both cases there is no good reason to reload the
registry, and it is actually a performance killer,
especially for cron workers that keep iterating on
the list of databases.
bzr revid: odo@openerp.com-20131011100313-4bud8e9xq2afp9z7
The previous fix in revision 5072 only allowed user names
that contained the exact same emails, but users will do
the wildest things like having `someone@domain.com` as
name but setting their email to `someone@domain2.com`.
This was blocked by our sanity check looking for a single
email in the From header. As this check is only done
in order to provide a better error message, it should
not impact valid cases.
Modifying the check to pass when at least one email
was found should be enough to catch most invalid cases,
without requiring a more advanced analysis of the
header value (the RFCs allows very strange things!)
bzr revid: odo@openerp.com-20130918143807-wqqpqomyu1ppa2ih
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
When a user has their email as name, the system will
construct the From header as "email<email>".
We previously forbade this, because the naive
check only counts the number of emails in
the From header.
We might need to drop that assert or implement
something better in the future.
bzr revid: odo@openerp.com-20130910143809-wu32dkz20es579nv
In some rare cases the dependencies have changed, and modules that newly depend
on a module that is not installed cannot be loaded on the first pass.
For technical reasons all installed/to upgrade/to remove modules have to be
processed before starting to consider new installations, so this requires
two passes.
In trunk the inner loop inside `load_marked_modules()` will be dropped
because it should be unnecessary.
bzr revid: odo@openerp.com-20130909150859-k8xykkorgnmv0xx0
In some rare cases the dependencies have changed, and modules that depend on an uninstalled module
will not be processed on the first pass.
bzr revid: odo@openerp.com-20130909095004-n1dp2w5wnlb36742
The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.
The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.
The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.
There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: odo@openerp.com-20130906134950-gi0szic3uw3onyuv
The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.
The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.
The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.
There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: odo@openerp.com-20130905170251-x47w1zrm43d0k9wb
By default everybody should be able to read and modify
filters, and this is coupled with a global ir.rule that
only permits viewing and touching global filters and
owned filters.
bzr revid: odo@openerp.com-20130903172606-7vn0z2gz71urfdtz
Launchpad Translations on behalf of openerp
Martin Trigaux
Christophe Simonis
Olivier Dony
Denis Ledoux
Stefan Rijnhart
Samus CTO (OpenERP)