Launchpad automatic translations update.
Launchpad automatic translations update.
[IMP] document create/delete=false in view definitions
Launchpad automatic translations update.
[FIX] ir.filters: deduplicate redundant ACL on ir.filters

By default everybody should be able to read and modify
filters, and this is coupled with a global ir.rule that
only permits viewing and touching global filters and
owned filters.
[IMP] update the documentation patch

add all supported attributes
add list of supported views
add example use case
add information about the default value of these attributes
Launchpad automatic translations update.
[DOC] module dev: description of view attributes @edit|@create|@delete, courtesy of Alexande Fayolle (Camptopcamp)
[FIX] res.partner: current name_search() implementation tends to skip a few valid results during early autocompletion - mitigation attempt

The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.

The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.

The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.


There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
Launchpad automatic translations update.
[MERGE] res.partner: current name_search() implementation tends to skip a few valid results during early autocompletion - mitigation attempt

The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.

The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.

The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.


There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
[MERGE] forward port of branch 7.0 up to revid 5067 odo@openerp.com-20130906134950-gi0szic3uw3onyuv