[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:
Defines
defines UXPROD-3816 R3 2022 | Thor Enhancements/Bugfixes/... Closed
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:

  1. Log into Lotus Bugfest
  2. Open the Courses app
  3. In the courses segment for searching, click in the location filter and type in 'mono'

Expected Results: see several location options appear, as in Inventory
Actual Results:  no locations found
**

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.

Generated at Thu Feb 08 22:22:40 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.