[MGNLUI-460] Search doesn't work properly Created: 21/Dec/12  Updated: 11/Feb/13  Resolved: 04/Feb/13

Status: Closed
Project: Magnolia UI
Component/s: framework
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Andreas Weder Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: framework, search, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0 (Snapshot: 2013.01.05 01:02:53) (Build: 5. January 2013, rev. b412b3be98c954e25f201c44ad35823f2ba7e56f)


Attachments: PNG File Bildschirmfoto 2012-12-20 um 11.17.37.png     PNG File Bildschirmfoto 2012-12-20 um 11.17.47.png     PNG File Bildschirmfoto 2012-12-20 um 11.19.14.png     PNG File Bildschirmfoto 2013-01-07 um 12.17.49.png     PNG File Bildschirmfoto 2013-01-07 um 12.17.58.png     PNG File Bildschirmfoto 2013-01-07 um 12.18.18.png     PNG File Bildschirmfoto 2013-01-07 um 12.18.28.png    
Issue Links:
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Please have a look at the attached screen shots: though I have several entries starting with "y" in the list, typing "y" as search term only returns those named exactly "y" and not e.g. "y6". Those are returned, however, if I type in "y6".



 Comments   
Comment by Federico Grilli [ 28/Dec/12 ]

search on node names will return hits when the node names "start with" the query term

Comment by Andreas Weder [ 07/Jan/13 ]

I'm afraid search still behaves somewhat odd. The cases I've listed have been solved (i.e. "y" returns both "y" and "y6"). But if I search of "6" or "0", I only get a subset of the nodes I should get. I'll attach some screen shots.

Comment by Andreas Weder [ 07/Jan/13 ]

Attaching first case: though the list of pages shows two pages named a6, a search of "6" only returns an event page containing "6".

Comment by Andreas Weder [ 07/Jan/13 ]

Another case: though the list shows two pages named "y0", a search for "0" only returns an empty list.

Comment by Andreas Weder [ 07/Jan/13 ]

Added the build I was testing this with.

Comment by Federico Grilli [ 07/Jan/13 ]

True. This should have been fixed just this morning, by implementing a contains() search on node names rather than startsWith().

Comment by Andreas Weder [ 07/Jan/13 ]

Thanks. I'll check again with a later build. Currently, the latest build of magnolia-bundle_trunk is still dating from Jan 3, but magnolia-ui is building.

Comment by Christopher Zimmermann [ 08/Jan/13 ]

Review:
Search in pages app does now work much better and addresses the explicit "y" problem reported.
However a few things are confusing.
1. differences between apps. Search on the node name is performed as if with wildcards on front and back. In the pages app, the first column IS the node name and therefore you get a very "forgiving" search. But in Contacts app if i enter the first few characters of the name, I dont get any hits. This is because the nodename is not the name of the contact. Confusing.

2. The full text search also searches the "abstract" for a page and so you can get many many hits that dont obviously relate to your search terms.

Still I think the work solves this ticket - please address a few of these complexities in the Concept paper for search so that future workers will understand what has been tried and what has worked and has not worked.
http://wiki.magnolia-cms.com/display/DEV/Search+and+Sort+concept+for+Content+Apps

Comment by Christopher Zimmermann [ 08/Jan/13 ]

Please update concept paper as discussed and commented.

Comment by Federico Grilli [ 04/Feb/13 ]

Going to create a follow-up ticket for concept update

Generated at Mon Feb 12 08:37:05 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.