The title field should not have a domain by default.
When a new record is created or the 'is company' field is changed, the onchange_type is triggered to restrict the domain accordingly to is_company field.
When an existing record is modified, there will have no domain on title field. It's not ideal but at least companies will be able to change the title without the need to modify twice the field is_company.
Fixes#1713
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.
This can give a performance boost on large databases
and should not be a concern in terms of access control
as the inheritance already grants access to the parent
records.
The one2many field 'user_ids' was initialized with an incorrect value for the
inverse field 'wizard_id', using a res.users id. The latter was causing a
MissingError exception. The fix is simply to not define explicitly the inverse
field in the one2many.
Also did a small cleanup of the code of the wizard.
- simplify the code by removing unused cases
- do not modify input argument 'value' of create/write
- do not call BaseModel.read() with reified group fields (this causes warnings)
On child partner creation of a parent partner, the commercial_partner_id is not computed (and stored) in the create method.
Therefore, we should compute the commercial_partner_id before trying to sync his data
The goal is to avoid any kind of prefetching
of other fields when copmuting the default
company, as this will sometimes happen in the
middle of a database update, when the default
company is used for setting the default value
of new columns. In that case the db schema
may not fully match the in-memory model, leading
to an SQL error.
- 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.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Loading the menus is the most expensive
operation for an average page load, and
the result does not change often.
The menu filtering already uses a separate
cache based on groups, but the rest of the
loading includes reading actions and
translating menu names, which is also
expensive.
Added a cache keyed on user + user
lang, plus relevant cache invalidation
when any of the following are touched:
access rights, user data including
groups and language, menus or mail.group
subscriptions.
The menu filtering cache is still
useful in parallel has it is invalidated
under different conditions.
User.has_group() is cheap but still
called very often, so it is an easy
win as well, and also frequently
used when rendering page templates.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
The goal is to ensure that HTTP requests
done while reloading the client (e.g. the
menu bar, etc.) do not use a deprecated
session context.
Also undo the previous fix from a0ee2b5
as it would cause other issues (e.g.
prevent setting the admin password/lang
when creating a new db using the db manager)
This logic does not belong in the business
methods of res.users.
Add group of countries res.country.group
Add get_fiscal_position method a method to compute a fiscal position based on company_id, partner_id, delivery_id
The meaning of res.partner.fiscal_position is now a forced a fiscal position.
The default implementation should handle simple cases, like VAT in UE and sales
tax in the US, but the method can be overriden to handle more complex ficals
rules.
In case of invalid format such as 'name email@server' (missing chevrons), the parsing would be failing due to a strict behaviour of getaddresses (returns nameemail@server).
With the patch this format is accepted.
opw 607312
When a module is uninstalled, this will also uninstall modules depending of it. To avoid unexpected loss of data, this patch list the modules that will get impacted during the installation.
This also affects the configuration pages with on change warnings.
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
This substitution was removed when res.font was implemented
based on the idea that it would be best to allow the use of
the real Helvetica/Times/Courier font if really required.
However the builtin ones are always available and crippled
when it comes to Unicode supports. Combined with the fact
that many RML/SXW reports had Helvetica hardcoded, this
breaks unicode reports for many users.
This patch re-introduces a mapping to replace the builtin
fonts by a few common and free alternatives (DejaVu, Liberation
and Free font families).
When an actual Helvetica/Times/Courier font is installed
no substitution takes place for it, in the hope that it
comes with decent unicode support.
bzr revid: odo@openerp.com-20140407121015-jq1qmg0hfu0dt31s
Martin Trigaux
Olivier Dony
Raphael Collet
Denis Ledoux
rlu-odoo
Christophe Matthieu
Xavier Morel
Fabien Pinckaers
sle-odoo
Fekete Mihai
Antony Lesuisse
Jacques-Etienne Baudoux
Amit Vora
Jaydeep Barot
Mansi Kariya
Christophe Simonis
Ruchir Shukla
qdp-odoo
Amit Vora
ged-odoo
Fabien Meghazi
Thibault Delavallée
Denis Ledoux
Jitendra Prajapati (OpenERP)
Richard Mathot (OpenERP)
Vidhin Mehta (OpenERP)
Christophe Simonis
Randhir Mayatra rma-openerp
Rakesh Sindhav (OpenERP)
Bharat R. Devnani (OpenERP)
Darshan Kalola