Inventory: Strip leading, trailing, and double spaces out of data in some elements (instance, holdings, item)
Description
Priority
Fix versions
Development Team
Assignee

Solution Architect
Parent
Parent Field Value
Parent Status
defines
is defined by
Checklist
hideTestRail: Results
Activity

Felix HemmeJanuary 20, 2025 at 8:13 AM
Hi @Khalilah Gambrell , long time not heard from this feature. I’ve added it to MM’s new Implementation Topics List and wanted to ask you if this is in scope for Trillium?

Raegan WiechertSeptember 14, 2023 at 4:07 PM
Not sure if this matters or not, but https://folio-org.atlassian.net/wiki/display/MM/2023-09-14+Metadata+Management+Meeting+notes could be added under the "Mentioned in" section above.
Thomas TruttAugust 9, 2023 at 4:55 PM
@Khalilah Gambrell and @Christine Schultz-Richert I was hoping that we could get this feature re-evaluated and hopefully prioritized for development. The one prior block for this issue was barcode data that Duke had, in that their barcodes legitimately contained trailing spaces. Even though that was a fringe case it would have greatly impacted them and created a showstopper. Since Duke will not be moving to FOLIO at this time, we were hoping this feature could be looked at again and implemented.

Autumn FaulknerAugust 9, 2023 at 2:55 PM
We are having spine labeling and scanning issues in Inventory due to leading spaces. These spaces get introduced sometimes by our label maker when we're interacting with some irregular barcodes we use at MSU. (It basically wants to add spaces for barcodes that don't have the full amount of expected characters.) While we are working on a solution to the label maker issue (which of course turns out to be more nasty than expected), this was not a problem in Sierra because Sierra ignores/normalizes spaces altogether.
Also, outside of Inventory, we find the spaces are not an issue. So we assume other Folio modules have this capability. Hoping this can be replicated in Inventory as well.

Marc JohnsonNovember 21, 2022 at 12:19 PM
@(OLD ACCOUNT) Erin Nettifee
Thank you for the follow up.
I'm fairly confident we could do the reprogramming, but if it didn't, either we would need that search to work or we would need some more meaningful error message than simply that the barcode wasn't found.
What kind of different error message would be wanted?
I'm asking because I'm unsure how we would differentiate once all of the spaces have been stripped from the data.
Details
Reporter
Debra HowellDebra HowellPO Rank
80Front End Estimate
XL < 15 daysFront End Estimator
Khalilah GambrellKhalilah GambrellFront-End Confidence factor
20%Back End Estimate
XL < 15 daysBack End Estimator
Khalilah GambrellKhalilah GambrellBack-End Confidence factor
20%Release
Not ScheduledRank: Cornell (Full Sum 2021)
R2TestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Reporter

PO Rank
Front End Estimate
Front End Estimator

Front-End Confidence factor
Back End Estimate
Back End Estimator

Overview:
We’ve discovered that it’s very easy, when copying and pasting data into, for example, the call number field in a holdings record, to include one or more leading or trailing spaces. It’s also easy to delete unwanted characters and end up with multiple spaces where there should be just one. This is impacting spine labeling. This same issue could cause problems with barcode retrieval. We’d like the data to be stored without the extra spaces.
"space" should be considered as a category, not a literal character, e.g., leading and trailing carriage returns & tabs should also be ignored
@Laura Daniels can provide additional details
Steps to Reproduce:
Log into some FOLIO Snapshot as user Diku_admin
Go to the Inventory app
In another tab open OCLC Worldcat, and find ..
Expected Results:
Actual Results:
Additional Information:
Will most likely require re-index, to get the white space not being indexed
URL:
Interested parties:
Developer Notes
Before this can be worked on, we need more information.
Which record types should this apply to? Is it every record type in inventory?
Yes
Which fields should this apply to? Is it all text fields?
All fields with Type “term” as identified here: https://github.com/folio-org/mod-search?tab=readme-ov-file#instance-search-options
Which characters should be removed? Is it the spaces, tabs and carriage returns or all characters than unicode considered to be whitespace?
Spaces, tabs, and carriage returns