locations cannot be sorted

[Ferdinand]

1. Currently the locations list has limited sorting features, because the "complete name" field is a function field that is not stored.
Making it stored would improve this, but it must not be "stored=True", otherwise it will not be correctly recomputed when ancestor locations are modified!
The store trigger must recompute all descendant locations too (child_of operator)!

2. Adding the parent_location to the search view could be useful too.

===== original description =======
the tree view of stock locations (not location structure - this one is OK) results in a list order by
 _order = 'parent_left'
which is not human readable / undertandable

together with the fact that function fields (Location Name = complete_name) can't be sorted this list is not user friendly at all
(sorting worked in V5)

BTW
IMHO the search view should have buttons for all "usages"
as well as a search field for parent location

please consider the missing sorting and filtering of function fields as a major issue for migration of complex installations to v6

[Ferdinand (office-chricar)]

It was already a problem to explain customers that many resources didn't show up sorted, that they have
1) to query all
2) click on header to sort

Now sorting s not possible any more - chaos is result

I consider the decision to drop the sort option for function ( and may be other) fields as a show stopper.

[Olivier Dony (Odoo) (odo-openerp)]

Here is a more detailed explanation on sorting issues in v5 and v6. I would like to be sure everyone understands this completely, so we can all save time next time:

Sorting in v5 was performed *client-side*, and only on the *currently displayed records*. This was not only wrong but very misleading. Imagine that you see the 80 first records sorted by name, and then you click on a date field hoping to see the latest or oldest entries... Result: you still see the same 80 records, just reordered by date. And you don't even know that there are earlier/older records! Totally incorrect!
So in v6 sorting is performed server-side, which is much better and safer. However this correctness comes with a caveat: in some cases sorting is not possible. Indeed, it is not possible to sort on function fields that are not "stored" or do not provide a smart "reverse function", because the only way to do it would be to compute the function field for the whole table first! Obviously this solution makes no sense for an ERP where tables can contain millions of records, and as we've seen, sorting client-side (even for function fields) is not better: incorrect and misleading. So we have the best trade-off at the moment, because correctness is much more important.

Of course we can improve the situation incrementally by making some function fields "stored" or providing "reverse functions", at least for the ones that are used in list views and are useful. But storing function fields is not always a minor decision - cache-invalidation and performance are of concern here.

Please keep the above in mind when reflecting about sorting questions.

[xrg (xrg)]

On Wednesday 27 April 2011, you wrote:
> Sorting in v5 was performed *client-side*, and only on the *currently
> displayed records*.
>...
> Please keep the above in mind when reflecting about sorting questions.

++

I can only see this problem improved[1] after some major refactoring of
osv/fields.py .
We have already had conversations in the community days about breaking that
big monster code into smaller, more modular, parts. Along with that, I can
imagine making provisions for smarter fields, that will have sort/group/search
support along with the traditional get/set functions[2]. I reckon, if we try
to fix now only one part of the problem, we will make our life harder for the
rest of the issues.

My suggestion has always been to implement more SQL magic in the framework[3],
and let the higher level code (the addons and their orm models, that is) not
worry about the db, not need to call cr.execute() ever.

[1] not entirely fixed, because there will always be remaining fields w/o
reverse function.
[2] some of this is already there, but only in pure python, in a rather crude
way so far.
[3] yes, postgres specific, tricks that only this db can do. (example:
windowing functions, stored procedures, recursive queries)
--
Say NO to spam and viruses. Stop using Microsoft Windows!

[Olivier Dony (Odoo) (odo-openerp)]

Now about the default sorting order for locations, the default order (_order=parent_left, combined with _parent_order=posz,name) will make the list appear as close as possible to the tree structure of the locations (as in "Location Structure") as we can.
This is the case because "_parent_order" being based on "name" means that they will be sorted by name at each tree level, and then the "_order" will make it so the final list is stored according to the tree structure: top to bottom, left-to-right, depth-first.
If you compare the "location structure" tree and the location list, you should see that the list shows the same result as the tree if it was fully expanded (this depends on the filters of course). Is that not the case for you?

It seems much more relevant to show the locations this way, rather than having a flat list of location names, which does not relate at all to their possibly very complex layout. Why do you think this is not "human-readable" or "understandable" ?

As a summary, I see only 2 valid "wishlist" points here, for which we can confirm this bug:
- "complete name" of locations should be a stored field, to make it possible to sort with it (it will not be very different from the default sort though, as the complete name obviously matches the tree structure too!)
- "parent location" could be added by default in the search view (for usability, even though it is simple to search on that using custom search)

[Ferdinand (office-chricar)]

please see the image

@Olivier:
"If you compare the "location structure" tree and the location list, you should see that the list shows the same result as the tree if it was fully expanded (this depends on the filters of course). Is that not the case for you?"

the structure is correct, but not the list.

at least "I" can not explain to users why this is sorted

but it is relatively simple to create a STORED 'complete_name' which must be a bit longer than 100 and which is recalculated for all children every time the name of a location changes.

[Ferdinand (office-chricar)]

here is a module I have done for products - which displays the products by category and name - easily readable for humans - basically the same usability issue

[Rohan Nayani(Open ERP) (ron-tinyerp)]

Hello,

Thanks for Reporting.
It has been fixed in lp:~openerp-dev/openobject-addons/trunk-bug-765559-ron
Revision ID: <email address hidden>
Revision num:4654.

It will be available in trunk soon,

[Ferdinand (office-chricar)]

any chance to get this into 6.0.x ?
it's really a showstopper

[Nathan (nathan-bowden-kiwi)]

We pointmatch with Ferdinand.
in our projects, we had used the similar solucion.

[qdp (OpenERP) (qdp)]

hi,

we have done as Olivier said:
"As a summary, I see only 2 valid "wishlist" points here, for which we can confirm this bug:
- "complete name" of locations should be a stored field, to make it possible to sort with it (it will not be very different from the default sort though, as the complete name obviously matches the tree structure too!)
- "parent location" could be added by default in the search view (for usability, even though it is simple to search on that using custom search)"

thanks