one2many and many2many fields depends on the security rules.
For instance, on products, with the taxes_id many2many fields, you only see the taxes of your own company, thanks to the multi company security rule
With related *2many fields, if you browse it with superuser, you will have all records of the one2many fields, even those you are not allowed to see, as superuser ignores security rules.
For instance, taxes_id of product.product is a related of taxes_id of product_template (through the inherits on product.template), and you should see the same taxes on the product template and on the product product (variant). This is not the case if the fields is read using the superuser
When the context contains 'recompute': False, the recomputation was not even
prepared. Now both create() and write() prepare the recomputation by invoking
method modified(). The flag only controls whether method recompute() is invoked.
In addintion, the former flag 'no_store_function' was converted to the flag
'recompute', so that both create() and write() use the same flag.
Fixes#1456
At the end of _prefetch_field(), a check is made to ensure that the cache
contains something for the field to prefetch. The check was incorrect because
the cache was checked for a regular value only.
The result of _convert_to_write() is intended to be pass directly to
`write()` or returned to the client (`onchange()` and `default_get()`.
`NewId` is as special value that must not be stored into the database
or exposed to the client.
On one2many fields writing in an existing record (not when creating new record), the computed stored fields of the one2many were not re-computed correctly
Computed stored fields were marked as modified only if no_store_function was not set to True in the context. no_store_function is set when writing one2many records on an existing record.
Now, these computed stored fields are marked as to be recomputed, but are recomputed later, at the end of the existing record write
When the addons_path config contained the
default path, the system was working with
an empty addons_path in the middle of the
other paths. This empty one matched for all
files, making all files appear to belong to
the root path component, e.g. `home` if the
root path is in /home.
Refactored a bit to avoid duplicates and
redundant path calculations.
On Launchpad, as commented on bug 933496, PO entries (and their comments) are
shared between series. This mean that e.g. the 7.0 series can have the wrong
`reference` comments (those beginning with #:) as they would be copied from say
the trunk series. Those `reference` comments are used to import translations
and look them up.
This patch adds a few lines of code to tools.translate so that targets
defined in the POT `reference` comments are used in addition to those from the
PO file.
Also adds a test module to validate the new behavior.
This patch stems from:
- the 6.1 branch by Vo Minh Thu:
https://code.launchpad.net/+branch/~openerp-dev/openobject-server/6.1-fix-po-targets-933496-vmt
- the 7.0 port by Numerigraphe:
https://code.launchpad.net/~numerigraphe-team/openobject-server/7.0-fix-po-targets-933496-vmt
The title of the partner is restricted with a context that will change in the onchange_type. Having twice the same field will not work well.
Remove the invisible attribute as the domain is handled by the domain.
Due to the multi-company record rule on gamification.goal,
each access to the Goals menu and each opening of the
Messaging menu (thus calling get_serialised_gamification_summary())
is extremely slow (with several thousands goals/users).
Adding auto_join to the user_id FK on goals makes it much
faster. However it causes crashes when reading the table
because the _order of gamification.goal uses `create_date`,
which becomes ambiguous after the auto_join with res_users.
Solving this can be done by re-implementing _read_flat()
in the ORM using the internal Query object, as in search(),
which takes care of fully-qualifying all column names.
Until this is fixed, a simple workaround is to use
start_date in the _order instead of collision-prone `create_date`.
Fixes the translation term import/export logic to
support terms inside QWeb templates.
Refactored a bit the export code so the babel-based
QWeb terms extractor for ./static/src/*.xml files
uses the same logic as the regular extractor for
ir.ui.views with type QWeb.
Server-side QWeb rendering uses a mix of the native
view inheritance mechanism and the template inclusion
(t-call) mechanism. During rendering the translations
are only applied at "template" level, *after* the
view inheritance has already been resolved.
As a result translations are local to a template,
not to the inherited view in which they are actually
written.
In terms of exporting PO[T] files, this is done by
resolving the "root" QWeb template a view belongs
to, and using it as the location of the translated term.
During import there is one extra quirk for QWeb
terms: they need to be linked to the `website` model
rather than the actual `ir.ui.view` model they
are really pointing to, so the rendering phase can
properly recognize them.
The new API introduced a small behavior change where empty
string values written or stored in a char/text field were
replaced by False (i.e. as if they were NULL).
This was done to mimic the web client behavior, but introduces
a very surprising effect: a.name = ""; assert a.name == "";
would fail. It would also require many more tests in the
code when reading existing required values from the database,
as they could still be False when an empty string value
had previously been stored, for some reason.
[FIX] Do not raise 500 error when an asset is missing
Note: those features are already present in master but could not be backported because the asset bundles are now completely different since the sass and less support where added.
If a forward porting occurs, you can drop this merge and keep master's version
After commit f28be81, boolean columns may have more
NULL entries than before. In the (rare) cases where
a boolean column was used for an ORDER clause
(e.g. in the /shop page of website_sale), this
causes a change of the resulting ordering.
By coalescing NULL values to false in SQL,
we make the ordering consistent with what the
framework does for domain expressions with booleans,
and when reading boolean values, that is, NULL is
the same as False.
- [FIX] bounce regex: too many emails were considered as bounce and therefore
not displayed in the chatter and lost for the communication history. The regex
was not correctly looking for the bounce alias in the email_to.
- [FIX] invite email: replying to the invitation email (invitation as new
follower) now replies to the user sending the invitation.
- [FIX] mass_mailing: added a column to store the id of the original email
in addition to the many2one column. The many2one is set to null when deleting
the original email. As the information is necessary, it is saved on another
field. The many2one is necessary for indexes purpose as the inverse of
a one2many.
In combination with f28be81, this should help speed up
initialization of new boolean columns. psycopg2 handles
bool parameters values just fine inside cr.mogrify()
Boolean fields always default to False in 8.0,
even when they do not have explicit default values.
This causes extra queries in the form:
UPDATE <table> SET <bool_field> = false
WHERE <bool_field> IS NULL;
Those are not necessary as the ORM automatically
folds NULL booleans to False, and can be very
expensive on tables with several million rows,
as the whole table may sometimes need to be
rewritten (can take dozens of minutes)
This is related to commit d31faceb67
(This is to avoid the runbot being yellow if on_change methods have extra keys in the returned value, this is not wrong, the web client will simply ignore them).
When you set the date of a cron the July 1st at midnight, if the user
time zone has a positive offset, then the converted UTC date is the
June 30th and adding 1 month will end up on July 30th translating to
July 31th instead of September 1st.
To solve this issue we use the super user time zone for the date
calculation.