The problem with the current approach is that it imports all modules in
order to discover which one exposes a subcommand by subclassing
openerp.cli.Command. At that time, the arguments are not parsed in order
to setup the config because a subcommand could potentialy alter the
command line arguments (which is the case of `start`)
This behavior causes the modules to be imported with the default config and all
the modules using some config keys at startup won't have to value they
are supposed to have when considering the shared command line switches.
Long story short:
$ odoo --workers=6
is ok, but
$ odoo start --workers=6
is not.
As the automatic subcommands are not used yet, we temporary disable it
until as proper solution is found.
The problem with the current approach is that it imports all modules in
order to discover which one exposes a subcommand by subclassing
openerp.cli.Command. At that time, the arguments are not parsed in order
to setup the config because a subcommand could potentialy alter the
command line arguments (which is the case of `start`)
This behavior causes the modules to be imported with the default config and all
the modules using some config keys at startup won't have to value they
are supposed to have when considering the shared command line switches.
Long story short:
$ odoo --workers=6
is ok, but
$ odoo start --workers=6
is not.
As the automatic subcommands are not used yet, we temporary disable it
until as proper solution is found.
In the Employee form, a remaining legal leaves field is available, which shows remaining validated leaves from allocation requests
As this is not allowed to delete a validated allocation requets, it shouldn't be possible to reduce the validated remaining leaves of an employee.
To reduce the remaining leaves of an employee, the user should cancel and remove the allocation request
- display_name uses name_get and not the other way around:
name_get should not call _compute_display_name, _compute_display_name should call name_get.
The previous behaviour was not backward-compatible with the old api.
All the models redefining name_get would have 2 different behaviors between name_get and display_name.
- Do not set an inverse function to display_name:
In most cases, writing on display_name writes on _rec_name (if any, not mandatory).
If the display_name computation is redefined, we need to redefine as well the inverse method to avoid unexpected behaviour
This required to also modify tests in base_import as readonly fields are avoided.
- Remove search method on display_name:
For the same reason as for the first point, it could be good that searching on display_name use name_search (and not the other way around).
However doing this would be very inefficiant (need to do the search, without limit, extract the ids of the name_get result just to generate
a subdomain ('id', 'in', [...]). As in most cases it would anyway mean to search on the _rec_name it's better to directly do so.
- Changing label to avoid mismatch:
In view displaying the list of fields or when a match is made on the label of a field (e.g. when importing csv file,
matching is made on both label and technical name), the fact that display_name field has '
Calling it 'Display Name' will avoid most errors.
- remove display_name definition from website_forum_doc,ir_model:
These fields are doing the same thing as the display_name of the new api, we can remove them.
We need to keep the one for res.partner as it's a stored field.
This fixes a bug in website_quote, because qweb tests whether address is
something that bool() casts to False or not, in order to display an icon (or not).
When searching on memberships, we use domain clauses in the format 'partner.x = y' where partner is a many2one to res.partner. The object res.partner has strict security rules for public users and this search will return zero result if not done with SUPERUSER_ID.
In addition, we need to access the list of products (membership_ids) in the domain to be sure we will retrieve only published membership (otherwise it would crash in the sort below).
The user_id is already set by the prepare_invoice method, which is called before the prepare_invoice_group (the user_id is already set, thus)
Besides, _prepare_invoice is overriden in sale_stock, to set the picking sale order salesman as user_id, and, without this correct, grouping invoicse by partner re-set the user_id to uid, which is wrong.
The state has been replaced by stage_id in the view, so the state is no longer used
Moreover, when doing an advanced search, the field state is visible and if used -> Traceback (because not available in the report sql table)
opw-609984
When computing defaults we may end up with
a falsy value that is not None (e.g. '' or False)
That value will be cast to None when being
saved in the database, depending on the column type
(e.g. saving False on a many2one actually stores NULL).
Improve the test to consider the value being written
*after* that conversion, to *really* avoid nonsensical
and expensive queries such as:
UPDATE table set col = NULL WHERE col IS NULL;
Due to the switch to Bootstrap 3.2 in this version, tooltip auto placement works erroneously (see https://github.com/twbs/bootstrap/issues/13897).
This is a workaround, waiting for a fix in Bootstrap assets.
(Closes#1341)
replace ormcache_context by ormcache: use the context in the cache key is useless
set skiparg=3 (default skiparg=2) so the uid is not used in the cache key: the filestore path is the same for all database users
Purchase orders created with invoice policy 'Based on incoming shipments' were not keeping the reference to the account analytic distribution when invoiced. opw 607577
Databases with thousands of users would experience
poor performance during any change to a group during
an update/install, caused by the prefetching of
all database users when the browse cache contains
most of the groups in the system.
Use site data dir instead of user data dir when user's home is not a directory.
Like system users created with /dev/null as home.
Stricter than before.
Fabien Meghazi