[UICR-160] Courses app: Location filters typeahead not working as expected Created: 22/Jun/22 Updated: 01/Nov/22 Resolved: 28/Oct/22 |
|
| Status: | Closed |
| Project: | ui-courses |
| Components: | None |
| Affects versions: | None |
| Fix versions: | 5.4.0 |
| Type: | Bug | Priority: | P3 |
| Reporter: | Molly Driscoll | Assignee: | Mike Taylor |
| Resolution: | Done | Votes: | 0 |
| Labels: | support | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||
| Sprint: | Thor - Sprint 151, Thor - Sprint 145, Thor - Sprint 146, Thor - Sprint 147, Thor - Sprint 148, Thor - Sprint 150, Thor - Sprint 149 | ||||||||
| Development Team: | Thor | ||||||||
| Release: | Nolana (R3 2022) Bug Fix | ||||||||
| Affected Institution: |
!!!ALL!!!
|
||||||||
| RCA Group: | Incomplete/missing requirements | ||||||||
| Description |
|
Overview: In the Inventory app, the effective location filter allows for typing ahead and will capture any locations containing your search term, regardless of where the term appears in the location. For example, for the location 'acq mono', you can type in the word 'mono' and have the correct location appear. In the Courses app, the location filter's typeahead appears to be left-anchored. So, in the example above, 'mono' does not return any results, but 'acq' does. This behavior persists in all the location filters within the Courses app: Courses: Location Reserves: Permanent location Reserves: Temporary location Steps to Reproduce:
Expected Results: see several location options appear, as in Inventory Additional Information: The typeahead is also producing a UI error if you try to type in '['. This does not happen in Inventory and should not happen in Courses either. URL: Interested parties: Erin Weller |
| Comments |
| Comment by Ann-Marie Breaux (Inactive) [ 23/Jun/22 ] |
|
Hi Charlotte Whitt There was no dev team on this bug, but looks like it should be Thor and UICR project. I added Thor. Could you review and adjust if necessary? Thank you! |
| Comment by Charlotte Whitt [ 23/Jun/22 ] |
|
Ann-Marie Breaux - for now we must leave the development team unassigned. So please do not automatically assign these tickets to Thor. Re. this bug, then I'll talk with Mike Gorrell whether this is work we must do or not. Thanks. |
| Comment by Ann-Marie Breaux (Inactive) [ 23/Jun/22 ] |
|
Sounds good - thank you, Charlotte Whitt |
| Comment by Anya [ 27/Jun/22 ] |
|
Support: What is the release? |
| Comment by Anya [ 11/Jul/22 ] |
|
support Charlotte Whitt - what release will this be correct in? |
| Comment by Anya [ 18/Jul/22 ] |
|
Support: Mike Gorrell can this be looked into to be fixed? |
| Comment by Debra Howell [ 25/Jul/22 ] |
|
From SUPPORT SIG: Charlotte Whitt Mike Gorrell Would you please assign a release to this bug and provide a status update? |
| Comment by Charlotte Whitt [ 25/Jul/22 ] |
|
Debra Howell - this work will be assigned to Mike Taylor. He'll look at it when back from vacation. This is work for Nolana. CC: Mike Gorrell |
| Comment by Erin Nettifee [ 18/Aug/22 ] |
|
To get to the point in the document - the Courses app does not use the Inventory look-ahead, that is why it functions differently. In my opinion, this is not a bug and should be queued as a feature request since the workaround is to do a left-anchored search. |
| Comment by Charlotte Whitt [ 19/Sep/22 ] |
|
Support SIG: Mike Taylor please provide an update on this ticket. |
| Comment by Mike Taylor [ 19/Sep/22 ] |
|
No progress. |
| Comment by Debra Howell [ 24/Oct/22 ] |
|
Mike Taylor Mike Gorrell Charlotte Whitt FROM SUPPORT SIG: What is the status of this bug? Will it be in Nolana? |
| Comment by Mike Taylor [ 28/Oct/22 ] |
|
Having looked at this in detail now, and read lots of code, I have to concur with Erin Nettifee that this is really a feature request. While Course Reserves uses the standard <MultiSelectionFilter> component (from stripes-smart-components), Inventory uses its own solution rolled from bits and pieces. We definitely don't want to copy the Inventory code across. I think the right way to address this requirement is to extend <MultiSelectionFilter> to take an optional parameter specifying how to do the candidate-value matching, and to use that. |
| Comment by Mike Taylor [ 28/Oct/22 ] |
|
Oh, hold the phone! There is a way to do this using the existing filter prop to <MultiSelectionFilter>, which it passes straight through to stripes-components' <MultiSelection>. That is documented, albeit not really adequately, at https://github.com/folio-org/stripes-components/blob/master/lib/MultiSelection/readme.md#common-props |
| Comment by Mike Taylor [ 28/Oct/22 ] |
|
I think this is done now. Y'all should be able to see it in action tomorrow on snapshot. (Since this is arguably a bugfix, I don't think it will be a problem to release it a day after the New Functionality deadline for Nolana.) |
| Comment by Charlotte Whitt [ 01/Nov/22 ] |
|
So cool, thanks Mike Taylor. Can I ask you to fill in the Release Fix Version/s information. |
| Comment by Mike Taylor [ 01/Nov/22 ] |
|
Done. |