We keep fold, because it has a meaning in kanban view, and is kind of
'drop' stage, for won / lost / cancel / dead.
New stage is now the stage with the lower sequence, not necessarily the
stage with sequence 1. Note that this could break the _track because it
checks for stages with sequence <= 1; however with OpenERP values it
works fine. In some specific stage configuration, some subtypes could
not be tracked precisely.
bzr revid: tde@openerp.com-20131023100429-a3vfxi5zkn18v6qq
After some experiments, having colors does not seem to give an
usable result on statusbar widget. Indeed we need to have the
current stage highlited, and maybe something to tell that some
stages have a special meaning and/or are the end of the pipe.
The closed field already gives that meaning.
Moreover the issue with the statusbar widget is that it indicates
state and action. Having both dimensions with colors / icons
is quite difficult to understand. We therefore stand on a simpler
version of the widget, only with stages and the current stage
highlighted.
bzr revid: tde@openerp.com-20131021104912-8ybhw0svdoghheh3
- stages: added some fields
-- closed: indicates whether this stage close the working process, for
example task ended, lead lost, applicant hired
-- bar_fold: whether to hide the state in the statusbar; this is different
from fold that is used for kanban views. Viewing a pipe or a specific
record are effectively different things and should use different fields.
-- bar_color: field to customize the stage in the statusbar (still WIP)
- impacted addons: crm, project, project_issue, hr_recruitment
- removed 'closed' addition in project_mrp as this is now in base project
module
bzr revid: tde@openerp.com-20131018132120-h0pv01q2bagtp99x
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
Thibault Delavallée