Merge lp:~openerp-dev/openobject-client-web/trunk-improved-searchview-cpa into lp:openobject-client-web/trunk
Status: | Merged |
---|---|
Approved by: | Xavier (Open ERP) |
Approved revision: | 4585 |
Merged at revision: | 4601 |
Proposed branch: | lp:~openerp-dev/openobject-client-web/trunk-improved-searchview-cpa |
Merge into: | lp:openobject-client-web/trunk |
Diff against target: |
61 lines (+7/-12) 2 files modified
addons/openerp/controllers/search.py (+1/-3) addons/openerp/static/javascript/search.js (+6/-9) |
To merge this branch: | bzr merge lp:~openerp-dev/openobject-client-web/trunk-improved-searchview-cpa |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Xavier (Open ERP) (community) | Needs Information | ||
Chirag Patel (OpenERP) | Needs Resubmitting | ||
Review via email: mp+50113@code.launchpad.net |
Description of the change
Hello,
Fixed search view issues, Check with the following steps.
steps:
Go to list view of partner(same - any object), add your custom filter and go to form view,switch back to list view and try to apply filter - group by or any thing.It doesn't work.I have to clear the filter first and then need to restart again so for example :
i) first I have filtered my data with country and opened form view for particular partner but then I feel I need some more filtration so will go back to list view
ii) and will try to add another filter,let say language - but at this time filters are not working ,neither custom nor default.Even group by is not working either.
Thanks.
* Why do you replace a JSON load by an eval (unrestricted too, not just a literal eval)?
* Why do you munge around with the filter value (removing '%') when the problem here is that this value should *not* have %'s in it because the server takes care of adding the '%' markers to ilike values?
* Could you explain what the problem was and why adding a conditional fixes it?
* from an efficiency standpoint, you added a conditional test within a loop. The loop is performed on the parent's children, and you test on the children's parent, so you could just perform the test on jQuery(this) outside the loop, which would avoid traversing the children and going up to the parent again. Either filter as now (via an if) or use .filter
* do not test visibility by checking for a CSS property, there is more to visibility than that and jQuery takes care of it via the `:visible` and `:hidden` pseudo-classes. They're also much clearer in terms of intent.