Call numbers with trailing spaces do not appear in browse by type options

Description

Problem: When a call number has a trailing space, that call number will not appear in the call number type browse options results - but does appear in Call numbers (all). This is reproduced in Poppy and Quesnelia and is reproduced with all call number types.

Steps to reproduce:

  1. Log on to Quesnelia bugfest

  2. Create an item on any instance

  3. Select call number type = Library of Congress classification

  4. Create a call number with a trailing space (such as “Test “)

  5. Navigate to Inventory Browse>Call numbers (all)

  6. Enter browse query “Test “

    1. Note call number exact match is found

  7. Enter browse query “Test”

    1. Note call number exact match is found

  8. Switch browse option to “Library of Congress classification”

  9. Enter browse queries “Test “, and “Test”

Expected results: Both queries (“Test “, “Test”) return an exact match

Actual results: Neither queries return an exact match, and call number doesn’t seem to be included in the browse results

Reported issue:

I found a handful of call numbers in Holdings record that had trailing spaces e.g., “ND497 R54 A4 1984 “. This call number will not appear when I go to Inventory > Browse by call number > Library of Congress classification.

I searched on:

  • “ND497 R54”

  • “ND497 R54 A4 1984”

  • “ND497 R54 A4 1984 “

The item does not appear in any of the results.

I was able to replicate this behavior by adding a trailing space to a call number in a different Item record.

The trailing space was automatically deleted from the Shelving order call number, “ND 3497 R54 A4 41984”. The instance will appear when I search on it in Inventory > Search > Effective call number (item), shelving order.

After I delete the trailing space from the call number field (in either Holdings or Item record), the call number will appear correctly in the browse results.

I rely upon the Call Number Browse results when assigning new call numbers to an item or holding. If this bug is not fixed, I may assign the same call number to two different works. It could also affect cutter numbers when I need to integrate new authors/artists into my shelf list.

This bug is related to UXPROD-3473: Inventory: Strip leading, trailing, and double spaces out of data in some elements (instance, holdings, item)

CSP Request Details

Not requested yet

CSP Rejection Details

None

Potential Workaround

Quick fix: Identify any call number fields with a trailing space and delete them. Could be done manually or via API. Long-term fix: Remove any trailing spaces in the call number field when the record (Holdings or Item) is saved. May be able to use some of the same code that derives the Shelving order call number.

Attachments

3
  • 26 Aug 2024, 11:05 AM
  • 26 Aug 2024, 11:05 AM
  • 07 May 2024, 11:04 AM

relates to

Confluence content

mentioned on

Checklist

hide

Activity

Show:

Christine Schultz-Richert August 29, 2024 at 4:00 PM
Edited

Reviewed in MM SIG on 8/29/24.

Out of scope/not addressed in this story: scenario with hard return in the middle of the call number. If there is a hard return in the middle, it will not be found in browse unless the hard return is added in the browse query.

Example:

  • Call number

    • MCN

    • FICTION

  • Must be browsed as

    • MCN

    • FICTION

  • Browse query “MCN FICTION” will not produce a match

Valery_Pilko August 26, 2024 at 11:05 AM

Verified on Snapshot environment - works as expected, user cannot create/update Call number with trailing spaces using “quickmarc” UI.
See attached screencast:

UIIN-2889_verified.webm

Note: Users still be able to create “Call numbers” with trailing spaces using “Data import” app, see attached screencast:

UIIN-2889_data_import_scenario.webm

Scenario with “Data import” is out of scope of the current ticket. If it should be handled, please create a separate ticket.

Hi - could you please review the fix on https://folio-snapshot.dev.folio.org/ environment? Thank you in advance!
cc:

Anya August 5, 2024 at 3:59 PM

Support: that is wonderful - thank you for the update

Christine Schultz-Richert August 5, 2024 at 2:31 PM

Hi - you are correct that this impacts all libraries. I have it as part of a Sunflower call number feature and I hadn’t yet updated the release on this bug for Sunflower.

Anya August 5, 2024 at 2:25 PM

Support SIG: ​@Christine Schultz-Richert We guess this affects all libraries- is our assumption correct..could this be solved with the other work you are doing re: browsing

Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Spitfire

Fix versions

Release

Ramsons (R2 2024)

RCA Group

Lack of testing

Affected releases

Quesnelia (R1 2024)
Poppy (R2 2023)
Orchid (R1 2023)

Affected Institution

OTHER

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created May 3, 2024 at 8:04 PM
Updated October 31, 2024 at 4:04 PM
Resolved September 2, 2024 at 12:27 AM
TestRail: Cases
TestRail: Runs

Flag notifications