In BOM, when performing an advanced search
on "BOM Lines" contains "a name"
all lines were returned, whatever the lines content.
This was due to the simple fact no field 'name'
was set on the mrp.bom.line model.
We set "product_id" as _rec_name, it seems the more
logical choice.
opw-631335
In the ecommerce, when adding a product to the cart
while having website_sale_options installed
the product was added in the cart within the
website default language, not in the current
language of the visitor. The description of the product
was in the default website language (for instance, English)
instead of being in the visitor language (for instance, French).
The reason is quite simple: With website_sale_options, routes
are called in javascript, and these calls do not include the
website language within the url to the route
(e.g., call to '/shop/modal' instead of '/fr_FR/shop/modal)
and the language in the request context is therefore
the website default language.
The solution proposed here is probably not the cleanest possible,
a cleaner solution would be to define a new utility
JS function within website javascript to perform
Ajax calls, automatically adding the language to the url path
according to the current visitor language.
Another solution would be to set the lang of the session context
to the visitor language, and to use this lang instead of the
lang within request.context.
Nevertheless, none of the two above solutions can be performed in
stable releases, such as 8.0, to avoid any risks.
opw-631400
Skip the creation of the corrective valuation entry
when a negative quant is reconciled with an incoming
shipment, when:
- the cost has not changed, so the journal entry would
be useless (credit/debit = 0)
- or, when the accounting period for the move causing
the negative quant is already closed, and must not be
updated (presumably the valuation was manually
set before closing that period)
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
After commit 0ed63d73a6,
the hack used to detect fields.function is not supported
anymore. Using `isinstance` is safer and cleaner anyway
(performance is not a concern here).
When switching an applicant to another stage,
there is the possibility to send an email template,
according to the given stage.
The attachments defined in the email templates should
be sent as well.
opw-630768
When auto subscribing to a message
(For instance, change the ```user_id``` field on a record,
like an invoice)
The new user is notified of the last message of the thread.
He must be notified of the parent message as well,
to have access to the first message of the thread,
to prevent access rights issues to the thread.
This mechanism is applied in the _notify method
of model ```mail.message``` as well, for the same reasons.
opw-630286
The timezone of hr_analytic_sheet should be the timezone
of the employee as well, so sheet analytic lines and attendances
lines are grouped within the same timezone, the timezone
of the employees, so the time difference between the analytic
lines and the attendances lines can be properly computed.
Fixes#5809Fixes#5379
Related to rev. 3bf1615ad4
Reduce memory footprint of server
The tricks used are:
- use a global LRU for `ormcache` (auto-balancing between registries);
- remove unnecessary data structures (binary class hierarchy of models);
- compute some data structures on demand (`_all_columns`);
- optimize field attributes (empty collections may be shared);
- optimize memory size of fields and columns by using slots.
On a database with modules sale, purchase and stock installed, the memory footprint of the registry went from 20.3Mb to 7.4Mb (as measured with heapy). In other words, the memory footprint was reduced to 1/3 !
In ormcache, those statistic numbers were counted per cached method for all
registries. We introduce separate statistic counters, and create a counter per
(database, model, method). The existing attributes that are no longer used
have been removed.
The registry size is now assumed to be around 10Mb, and ormcache size is
proportional to the maximum number of registries. Statistics about ormcache
usage is shown to the log when receiving signal SIGUSR1.
In `__getattr__`, remove the test on accessing `_attrs`. This situation should
never happen, since the attribute `_attrs` is set in method `__init__()`.
Introduce slots on all field classes for common attributes; slots take much
less memory than a `__dict__`. The other attributes are stored in a dictionary
`_attrs`; all fields with an empty value for `_attrs` (common case) share the
same empty dictionary. This saves quite some memory (around 4.5Mb per
registry), given the number of field instances created for a registry.
Another mechanism is used for the default values of attributes, since slots
cannot be assigned on classes.
The optimization consists in using tuples for attributes `inverse_fields`,
`computed_fields` and `_triggers`, and to let them share their value when it is
empty, which is common. This saves around 1.8Mb per registry.
This saves about 400Kb per registry by not allocating those lists, which are in
most cases empty. The removal of the attribute will also simplify a bit the
management of free attributes.
The computed value of parameter digits is no longer stored into fields and
columns; instead the value is recomputed everytime it is needed. Note that
performance is not an issue, since the method `get_precision` of model
'decimal.precision' is cached by the orm. This simplifies the management of
digits on fields and saves about 300Kb per registry.
Sometimes, the expected mro of the model is not the same as the one built with
a binary class hierarchy. So we reorder the base classes in order to match the
equivalent binary class hierarchy. This also fixes the cases where duplicates
appear in base classes.
Instead of composing classes in a binary tree hierarchy, we make one class that
inherits from all its base classes. This avoids keeping intermediate data
structures for columns, inherits, constraints, etc. This saves about 600Kb per
registry.
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.
QWeb templates can be translated, javascript code
included. Nothing prevents you to translate
the javascript reserved word "undefined", for instance.
Preventing the livechat JS snippet to be translated
prevent translations mistakes, like translate
```undefined``` by ```Niet gedefinieerd```
opw-630335
The BBA communication is now only checked when provided as input
(created or modified).
Avoids useless check for uniqueness when it's not modified, and
prevent errors when several invoices are modified in batch.
opw: 629649
Closes#5700
The same holds for the inverse history_ids relationship. When an object is copied,
the many2many fields their links are copied.
When we copy a done move as is done in the return wizard to create the reverse, it copied also
the relationship with the quants. This is problematic as this field indicates the quants that
were transferred by the move and the new move will think it will have returned all the quants
even before it is done.
In the accounting settings, we prevent having gain and loss accounts that are linked to a
different company than the one selected for the chart of account.
opw: 630494
Currently, the view_form search_count doesn't propagate the context, so when
searching on a translated field, the count can be different than the one we
would expect and get with a search in a current language different than en_US.
opw-628792 opw-630212 closes#5825
`product_qty` field is not recomputed at record creation.
Force field recomputation at any change
Removing the trigger on `product.product` should not be a problem as
product uom can't be changed once there are move lines.
opw:629650
Richard Mathot
Laurent Mignon
Denis Ledoux
Goffin Simon
Christophe Simonis
Loïc BELLIER
Olivier Dony
Antony Lesuisse
Anton Chepurov
Raphael Collet
Nicolas Martinelli
Josse Colpaert
Nicolas Lempereur
Nicolas Piganeau