When a record is created with a field property of type integer or float equal to 0, there is
no record created in ir_property for this field. Then for a search of a record with this type of
field equal to 0, it must match all the records that have no corresponding property in the table
"ir.property" for this field.
ps: in 7.0, the function search_multi doesn't exist and the bug linked to cost price
doesn't happen because it's a float field.
opw:639746
When receiving goods with average price set as costing method,
for a move from another company than the SUPERUSER_id company,
the average price updated was the one from the SUPERUSER company
instead of the one of the move.
opw-634167
In commit 04ba0e99, we introduced an optimization for reading inherited fields
in a single query. There is an issue when you have more than one level of
`_inherits`. The query looks like:
SELECT ...
FROM table0, table1 AS alias1, table2 AS alias2
WHERE table0.link0 = alias1.id AND table1.link1 = alias2.id AND ...
^^^^^^
should be alias1
This fixes the issue, and adds a test to reproduce it. The fix is based on
@emiprotechnologies's own proposal, but is cleaner and does not break APIs.
When importing a CSV file with an "id" column containing
external IDs (XML IDs), the system automatically creates
or updates the corresponding ir.model.data entries.
This would fail for regular users who do not have
create/write access on this internal model.
When searching if a many2one property field is not set, there may be less
results since only the ones with a reference set to NULL are returned.
We should also get those not in the table.
This commit change this case so instead of returning ['id', 'in', {matching non-set ids}],
the ['id', 'not in', {matching set ids}] is returned.
e.g: if (1, 3, 8) are set, (5, 9) are not set. ['id', 'not in', (1, 3, 8)] would
be returned instead of ['id', 'in', (5, 9)] which might not select all non-set
property fields.
closes#6044
opw-631057
The ir.ui.view.graph_get() method depended on the natural
semi-random order of Python dict keys in the _columns dict.
When the number and/or names of the _columns happened to
yield the o2m field of the "incoming transitions" *before*
the "outgoing transitions" of the "Node model"
(e.g. workflow activity), it would swap the incoming and
outgoing transitions fields around, causing a crash later
in the `tools.graph.process` method (currently an infinite
loop in the `tree_order()` method of tools.graph.py).
Closes#3614
Fixes https://bugs.launchpad.net/openobject-server/+bug/1316948
opw-633765
The defaults of ir.values depends on the user company, but there is no
cache invalidation when the company of a user change.
This fix adds the clearing of the default's cache in this case.
Closes#6339
opw-629979
When updating translations, the source (`src`) is irrelevant for
`field` and `help` translations. Theses translation types are only
matched through their `name`.
In the small cases where utf-8 is not escaped in the CSS of a module*, an error
could happen when breaking minified CSS on multiple page (for IE9).
For the issue #5050
*currenlty for 8.0 : https://gist.github.com/nle-odoo/e353b22f89031ced21a5
On internet explorer 6, 7, 8 and 9, the limit of CSS rules in a stylesheet is
4095 (http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164546.aspx).
This commit breaks down a CSS bundle in several pages for these IE versions.
To do this, the CSS tag added is of the kind : /web/css.0/{xmlid}/{version} in
which there is:
- the whole CSS if there is no more than one page,
- a list of @import pointing to the multiple pages.
note: if a modification lowers the number of page, an old page may stay in
ir_attachment (e.g: go from 4 to 3 pages, the old 4th page of another version
will not be deleted untill the number goes again up to 4).
Note: the method css(self) previously returned an unicode variable (the first
time) or an str variable (the following times, if already cached), the fix
also correct this so an str variable is always returned.
fixes#5050
opw-627116
fails due to ir.config_parameter permission
At rev. 80017b04c2
ir.config_parameter model has been restricted to employees
Getting parameter from this model should therefore
be done as SUPERUSER_ID where the uid could
be a user which is not an employee.
Closes#5280
This rev. is related to eb9113c04d
if a model or a resource id is not defined on an attachment
restrict access to employees only if the creator
of this attachment is not the current user.
So non-employees can access their attachments without
models/resource id, which includes attachment of
discussions threads.
Fixes#4309Closes#4310
Special case for binary attachments with an url, when there is no data
to serve. If the attachment name is an url, redirect to this url,
otherwise return a 204 HTTP error.
When going to logged calls through opportunities,
and no logged calls were listed,
the mail alias of opportunities was displayed
within the placeholder help message,
wrongly, as we were in the logged calls list.
This was due to a context propagation, due
to have defined empty_list_help_* keys within
window actions. It was the case in several
modules.
Besides, we do not find the usefulness of the
custom_context passed to the get_empty_list_help
method: indeed, none of the methods get_empty_list_help
overriden in modules need any other keys than
'default_type', which do not require an evaluated
context.
We therefore remove the whole code regarding this
custom_context, and we therefore get rid of this
useless context evaluation thing within one of
the most accessed method of the web client.
opw-630673
Due to a compatibility problem between the new API
implementation and the @ormcache decorator, the
context parameter of ir.attachment._filestore()
was dropped at rev. 0beb14f0d2
However the need for caching this method has
disappeared in Odoo 8 (it used to require a
DB query). So it is even better to drop the
@ormcache decorator altogether, and keep the
context parameter.
This avoids a useless change of method signature,
even if that was on a private method.
Make sure pass a list of ids instead of a single id to write calls.
Some models (e.g. blog.post, fixed at 12fc5ea) are assuming that it got a list
of ids and is not checking the type.
Always pass a list of ids as it's the expected format for the orm.
Commit 540b753bf8 introduced
support for resources stored as ir.attachment records in
asset bundles too.
This is specifically useful for customizations.
However the HTTP route for reaching those resources
when they are *not* in a bundle was originally created
in the `website` module (as a special handling for
404 requests)
This means that these dynamic resources would only
be partially supported when `website` is not installed,
causing various problems:
- missing resources in debug mode where bundles are skipped
- errors when trying to define new client-side Qweb templates
via XML resources - which are loaded with a direct request
- ...
This commit moves back the supporting code to the web module.
The `mimetype` column is not present in ir.attachment without
the `website` module, but sniffing it based on the attachment
name works fine at serving time too.
Closes#6002
The implementation of `ormcache` does not work on methods that take a `context`
parameter. Because of the decorator `decorator`, the arguments of the call are
passed positionally to the method `ormcache.lookup`, and positional arguments
are used in the cache key.
The fix consists in removing the `context` parameter from the faulty methods,
either directly, or by caching a private method called by the public method.
Since revs 53582c2ea6 & f65c913027,
this was no more possible for portal users to read groups
on purpose, for privacy reasons.
fields_get of res.users model is overriden, for
the access rights form view features
(The groups selections and checkboxes).
At each call to fields_get, which happens at each call
to fields_view_get on the res.users model, operations are
done on the model res.groups (basically, to
build the selection groups and checkboxes). So,
each time a view of model res.users is displayed,
whatever the view, operations on res.group model were performed.
The thing is, these operations on res.groups
are actually needed only for the user access rights
view, or at least only for users having the group
Administration > Access rights. These group operations
aren't needed for the preferences view, nor for portal users.
We therefore avoid to do these if the user is not part of the
Administration > Access rights group, which lead to
performances improvment, and solves the fact
portal users couldn't access their user preferences view.
opw-627391
The mappings model._all_columns takes quite some memory (around 2MB per
registry) because of the numerous dictionaries (one per model) and inefficient
memory storage of column_info. Since it is deprecated and almost no longer
used, it can be computed on demand.
The ormcache is now shared among registries. The cached methods use keys like
(DBNAME, MODELNAME, METHOD, args...). This allows registries with high load to
use more cache than other registries.
When a `noupdate` record is processed during an update,
the update_dummy method marks the record as "seen" so
it won't be deleted at the garbage collection step,
and seen as an obsolete external ID.
This needs to be done also for the parent records via
_inherits, because they have also received an implicit
external ID at creation, and must not be garbage
collected, even if their `noupdate` flag (db side)
is not set because the flag was added later.
This rare problem could be reproduced by creating a product
in a module, then referencing it in e.g. a sales order,
then updating the module after changing the product
record to be in a `noupdate` block.
At the end of the update the implicit product.template
record would be garbage collected, and trigger a cascade
deletion of its children - blocked by the SO reference
to the product.
The invalidation in registry was done only if the field's model was already in
registry. This situation is not the case when you create a custom model with a
custom field.