[6.0 RC1] products filter location and group by category give wrong results

[Ferdinand]

to reproduce
clear
extra filter location=output (looks OK without investigating the data)
group by category
some issues
- every row shows 0 values
** negativ value of virtual stock missing [PC1]
opening any of the categories - shows all products + quantities (presumably of all stock locations)

IMHO it's a real drawback not beeing able to filter "Real Stock"
Example
* "Real Stock" is not 0
to show only available products

[xrg (xrg)]

On Thursday 23 December 2010, you wrote:
> ** Project changed: openobject-addons => openobject-server
>
This issue looks interesting.. ;)

[xrg (xrg)]

On Wednesday 22 December 2010, you wrote:
> Public bug reported:
>
> to reproduce
> clear
> extra filter location=output (looks OK without investigating the data)
> group by category

I did a quick analysis of the current implementation[1] and verified my initial
hunch:
 - function/related fields are *not* computed by the orm.read_group(), meaning
that sums like the "qty_available" of "product.product" will not appear in
grouped lists.

In a related note, the fact that "0.0" appears rather than <Null> empty
columns[2] at the GUI may be wrong. It's due to our other "null means zero"
mis-feature of the framework.

I realize that the current behaviour is far from the expected, as you have
correctly requested. Still, I'm reluctant to start patching the framework of
v6.0, at this stage, for that.
One reason is that I hope we can get much better SQL-oriented handling of
complex queries after v6.0. That, would be the best solution, more efficient
than a pythonic "dirty sum" that we would write for the current ORM.

I'm waiting for the other experts' opinion on the roadmap of this bug. Shall
we defer for v6.1/v6.2 ?

[1] some parts of the code are not my expertise, but I like to read them.
[2] even after writting an agregation framework for these columns, we shall
expect some modules to have non-aggregate compliant columns. For those, we
need to return an empty/not-available/unknown indication.

[Ferdinand (office-chricar)]

- I agree on mis-feature "null means zero" should be fixed asap after 6.0

- function/related fields are *not* computed by the orm.read_group(),
it is not feasable to explain this to clients/prospects/users - they simple do not care about internal limitations.

[xrg (xrg)]

On Monday 27 December 2010, you wrote:
> I agree on mis-feature "null means zero" should be fixed asap after 6.0

> > function/related fields are *not* computed by the orm.read_group(),
> it is not feasable to explain this to clients/prospects/users - they simple
> do not care about internal limitations.
Well, the explanation is one sentence: We have to freeze the feature set and
release now, for the sake of keeping the "product" in the market.

Freezing includes keeping mis-features that we don't like. Its a compromise
between having a perfect version and having something stable to give to our
customers/friends/followers/community.

[Ferdinand (office-chricar)]

I hope to read this issue in release notes.

[Christian Sprauer (csprauer)]

I would like to emphasis Ferdinand's point here :
>("function/related fields are *not* computed by the orm.read_group(), it is not feasable to explain this to clients/prospects
>/users - they simply do not care about internal limitations.)

The "Group_by" is a key innovation of V6 and it should work seamlessly for related/ function fields. Group_by represents huge productivity gains for end users, because what they typically do today is a) extract data from the DB into excel, b) make a few functions, c) do a pivot chart to aggregate the data, d)play with the pivot chart in a graphical manner to make sense of their data. I have seen this a million of times. Many end users are familiar with pivot charts and the group_by feature in OpenERP V6 comes very close in terms of functionality.

In contrast, "SQL based" reports are more powerful but much less user friendly. They typically require some degree of programming skills (which means time and money to extract datas that are allready in some form in OpenERP - this is difficult to explain to customers) and it may take time until a "user adopted" OLAP module is developped.

I would therefore argue for a high importance of the "Group_by" feature on related/function field (even if it takes some dirty python for now). End users will appreciate it and productivity gains may be greater than with SQL reports, because it's so much flexible to decide what field you want to group by.

A related problem, which bugs me for some time, is the ability to get a related field directly in a view without defining it as a function field or related field in the python code (apologies if this sounds crazy, I am not an expert programmer), using relationships of relationships syntax like in the rml reports : sourceobject.relationobject1.relationobject2.relationobject2fieldname ?
If this later element is not related to this bug please let me know, i will post another bug (or feedback).