Course Materials: Browse for course not working

Bug #1913815 reported by Michele Morgan
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.10
Fix Released
High
Unassigned

Bug Description

When performing a browse search for courses, the results list always displays the first ten courses alphabetically.

Also, the closest course name to the search term only appears in bold if the case matches.

For example, given courses named:

Aardvarks
Beavers
Cats
Dogs
Elephants
Foxes
Giraffes
Horses
Iguanas
Jackals
Koalas
Zebras

A browse search on "aardvarks" and a browse search on "zebras" both retrieve the same list, Aardvarks - Jackals.

The browse term "aard" will not cause the Aardvarks course to appear bold, but the browse term "Aard" WILL cause Aardvarks course to appear bold.

The same behavior is true whether you browse by course name or course number.

Revision history for this message
Garry Collum (gcollum) wrote :

Course names beginning with a lower case letter also sort after course names beginning with upper case letters.

tags: added: opac
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Kyle Huckins (khuckins) wrote :
tags: added: pullrequest
Michele Morgan (mmorgan)
Changed in evergreen:
milestone: none → 3.8.1
Revision history for this message
Beth Willis (willis-a) wrote :
  • Course Browse.docx Edit (103.8 KiB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)

EG 3-8-0

1)  Browse terms do appear to be case insensitive, except when the term matches the name exactly *except* for case.  For example, using the courses listed in the initial bug report, browsing for the term "koalas" returns the first 10 courses as if there is no match.  (See first screenshot.)  A browse for the term "Koalas" does result in a match and the course is bolded.

2)  When the browse does result in a match, the matching course appears at the top of the list of results.  (See screenshot 2)  This is different from how the regular catalog browse works, where the matching term displays in the middle of the listed results. (See screenshot 3)

3) If no match is found, the first 10 results always display.  This is different from the catalog browse where the closest match is displayed in the middle of the results list.  (See screenshot 4.)

4) Course browse does not respect the scope.  All courses are browsed regardless of the scope selected.

tags: added: needswork
removed: pullrequest
Revision history for this message
Kyle Huckins (khuckins) wrote :

I've pushed a couple of commits addressing 1 and 4 in the above findings, but I'm having trouble with 2 and 3 - I've tried a few different ways to handle both centering the list on the matching result, as well as having it find a best match - if anyone has any ideas, let me know. For now, it may be worth creating additional bug reports for the centering aspect and best match improvements

tags: added: pullrequest
removed: needswork
Revision history for this message
Beth Willis (willis-a) wrote :

Related to point 1 in Comment # 3, the case insensitivity issue is resolved.

However, the "starts with" functionality has been lost, browse now appears to require an exact match.

For example, given the list of courses above, if you do a course name browse search on "z" or "zebra" or "Z" or "Zebra", you should retrieve the "Zebras" course. Instead, any of these browse terms results in no matches and displays the list of courses from the top.

Similarly, given a course with number "ZOO 101", if you do a course number browse on "zoo", the search results in no matches and displays the list of courses from the top.

Related to point 4 in Comment # 3, browsing now appropriately respects the selected scope.

However, only courses owned by the selected org unit are retrieved. Scoped course browse should behave like other catalog browse searches. If you browse at system level, you should find courses owned by the system and its branches. Likewise, if you browse at the Consortium level, you should find all courses owned by any branch or system within the consortium, as well as courses owned by the consortium itself.

Kyle Huckins (khuckins)
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Revision history for this message
Kyle Huckins (khuckins) wrote :

Two more commits made -

The first one fixes the case sensitivity and matching issue - the API should now properly ignore case sensitivity while retaining the intelligent matching it had previously

The second fixes the scope error, making sure we're grabbing all descendant org units

Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
Revision history for this message
Jennifer Pringle (jpringle-u) wrote (last edit ):

I've marked this as a bootstrap-blocker because some libraries won't be able to use the course reserves module until the browse scopes properly.

tags: added: bootstrap-blocker
Revision history for this message
Beth Willis (willis-a) wrote :

Scoping now works correctly. So, browsing for courses at the system level returns matches from courses owned by any branch within the system. Browsing for courses at the consortium level returns matches from courses owned by a system or branch within the consortium.

There is a problem with exact matching again, though. If the browse term(s) matches the course name or course number exactly, no match is found. This issue is not related to case-sensitivity. For example, using the list of courses noted in the original comment, browsing for either "Jackals" or "jackals" will not find any matching course names.

Changed in evergreen:
milestone: 3.8.1 → none
no longer affects: evergreen/3.7
Revision history for this message
Terran McCanna (tmccanna) wrote :

Removed pullrequest based on testing comment #8

tags: added: needswork
removed: pullrequest
Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

This continues to be an issue in 3.9

Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

I'd like to advocate for an importance of Medium or High for this bug. Until this bug is fixed the Browse Course feature is unusable. (We've hidden the option in our OPACs in order to use the course reserves module.)

Changed in evergreen:
importance: Undecided → High
tags: removed: bootstrap-blocker
Michele Morgan (mmorgan)
Changed in evergreen:
assignee: nobody → Michele Morgan (mmorgan)
Revision history for this message
Terran McCanna (tmccanna) wrote :

I've marked this High.

Revision history for this message
Michele Morgan (mmorgan) wrote :

I've made a tweak to Kyle's branch to fix the exact matching problem in comment #8.

It does not address issues 2) and 3) in comment #5, but it does make the course browse functionality at least usable. Given the importance, perhaps we should consider pushing these fixes and addressing additional issues in separate bugs.

Working branch (top 6 commits) at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1913815_course_browse_fixes

user/mmorgan/lp1913815_course_browse_fixes

tags: added: pullrequest
removed: needswork
Changed in evergreen:
assignee: Michele Morgan (mmorgan) → nobody
Changed in evergreen:
assignee: nobody → Jane Sandberg (sandbergja)
Changed in evergreen:
assignee: Jane Sandberg (sandbergja) → nobody
Revision history for this message
Jane Sandberg (sandbergja) wrote :

Huge improvement! Thanks, Kyle, Michele, and Beth. I pushed this to rel_3_10 and above, and opened two new tickets for the outstanding items that Beth identified: bug 2032574 and bug 2032575.

Changed in evergreen:
status: Confirmed → Fix Committed
milestone: none → 3.11.2
tags: added: signedoff
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.