Split low level dispatching and high level dispatching.
Low level dispatching is used when the db is unknown it's only used by a few
controller in base and web.
High level dispatching is used when the db is known, it is used by most
controllers and it handles authentication and errors. Because it's a regular
osv object all it is fully overridable by openerp modules.
bzr revid: al@openerp.com-20131110014609-io03vspj2q1wtqa0
Depending on the way the search view is setup, a single item
(e.g. "Search foo for bar") can follow a list of a bunch of
completions. In that case, it is hard to notice that it's not just one
more item of said list.
Add a marker on the first of every completion list in order to catch
1-item lists (or lists without titles/categories) and prepend a small
border every time, so that single-element completions following
lists-with-titles can be noticed.
bzr revid: xmo@openerp.com-20131107112858-1xyvcesize0doblz
Similarly to the recent fixes in Purchase Analysis,
the Sales Analysis view must not group on the quantity
field. It is one of the columns that must be aggregated,
not used to fold PO lines into the same
result row.
The line count was also incorrect because of this, and
had to be corrected to actually count() the underlying
SO lines.
In addition, the JOINs were done in the wrong order,
which could cause problems (e.g. if an empty SO ever
landed in the database, all the SO line columns
would be empty in the JOIN, and cause errors)
bzr revid: odo@openerp.com-20131105103011-vkix07lsb6q3y9fd
The product quantity is one of the columns that must be
aggregated, not used to fold PO lines into the same
result row.
This, combined with missing aggregation operators
was causing multiple identical PO lines from the
same PO to be merged together and only counted once
in some aggregations.
bzr revid: odo@openerp.com-20131105101930-f2qbcp12luom08je
It is a common need to set a higher decimal precision
for `Product Price` (i.e. the product cost field) for
high volume / low value items. This may typically
require up to 4-6 decimals for e.g. EUR/USD-based
companies where the currency has 2 decimals.
In that case the product cost should be stored with
full precision without applying the currency rounding.
The appropriate currency rounding will be applied
anyway as soon as a transaction actually uses that
product cost (typically in a SO/PO)
bzr revid: odo@openerp.com-20131104173232-84g115x6ykxoc1rh
While processing a picking we must keep track of
previously processed lines as they modify the
stock on hand but are not yet included in the
`qty_available` function.
Negative stock on hand is handled as if
the stock was zero as far as the average
price computation is concerned.
bzr revid: odo@openerp.com-20131104171245-z1lgsplyu4cdz9gc
Without the right precision the default rounding is
applied and causes a possible loss of precision when
the `Product Price` precision is increased.
This can in turn lead to incorrect average price
computations.
bzr revid: odo@openerp.com-20131104170118-ls5q0yridevw0jgt
The starting table for Purchase Analysis is purchase_order_line
not purchase_order. The previous code was using a wrong JOIN
combination starting from purchase_order, which resulted in
a crash if an empty PO was created.
In order to prevent this an extra WHERE clause on product_id
being NOT NULL was added, but this was incorrect too as it
prevented PO lines with no product_id value from appearing
in the Purchase Analysis results, while being perfectly valid.
bzr revid: odo@openerp.com-20131104165826-kltuzlh4i8q89sk0
When processing a translation, the module used to replace the original term by the translated value for accounts (only object with force_write=True). Now getting real multilang feature.
Generates the accounts with no language to get the untranslated value
bzr revid: mat@openerp.com-20131104095729-hwh2cocudxnhunyz
message_update. This behavior makes sens only in message_new when
setting initial parameter of the applicant, not when somebody sends
an email on the record.
Removed priority change when there is a 'priority' key in msg; but
this key is not likely to be present in a parsed email.
Removed updated values change due to a mapping of values present in
the email. This code was a copy-and-paste from crm and did not have
any meaning in hr_recruitment.
Also removed unnecessary code in project, project_issue, crm_helpdesk
and crm_claim for the same reasons as for hr_recruitment.
bzr revid: tde@openerp.com-20131104092731-ixasweoy1dbllbb3
As `new Date()` return the current date, when we are the 31,
setting the month to a month with less than 31 days will change
the date to next day (1st of next month). This result to a date(time)
object one month ahead of the wanted date(time).
bzr revid: chs@openerp.com-20131031103333-vt68132ptj9sbr04
Antony Lesuisse