DDC call numbers with long subdivisions not printing correctly

Bug #1811898 reported by Elaine Hardy on 2019-01-15
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Adam Bowling
3.1
High
Unassigned
3.2
High
Unassigned

Bug Description

DDC numbers with more than 5 digits past the decimal point do not display or print correctly in Print labels

Call numbers such as "658.809070573 G" should display and print as:

658
.80907
0573
G
(depending on the size of the label and the call number wrap filters set for height and width.)

Instead, they display only the class and division portion of the number, the subdivisions, cutters and other information do not display or print:

658
.
.
.
.
.

This also occurs with call numbers containing prefixes as part of the call number:
REF 398.097303 A

REF
398
.
.
.
.

This just occurs with call numbers with long subdivisions and not with long call numbers generally. The call number: "658.4053 C74895 Disc Gde" displays and prints as:

658
.4053
C74895
Disc
Gde

"NONFIC 398.0973 AXLEROD" and "MYS PATTERSO JAMES C" display as:

NONFIC
398
.0973
AXLERO
D

And
MYS
PATTER
SO
JAMES
C

To complicate matters, the interface will not let you edit call numbers as separate call numbers in the Call Numbers tab if more than one number displays with the same class/division number . For example, if you have four call numbers in one print job displaying as:

658
.
.
.
.
.

editing one edits all four to the same call number, regardless if the numbers differ in the item record. (I will be reporting this as a separate bug since it has broader implications)

(I used quotes around call numbers above to make them easier to distinguish here. They don't actually have the quotes)

Changed in evergreen:
importance: Undecided → High
Elaine Hardy (ehardy) wrote :

Bug report for inability to edit identical call numbers separately is https://bugs.launchpad.net/evergreen/+bug/1811899

Adam Bowling (abowling) on 2019-02-06
Changed in evergreen:
assignee: nobody → Adam Bowling (abowling)
Jennifer Weston (jweston) wrote :

Confirmed. Evergreen 3.1.6

Changed in evergreen:
status: New → Confirmed
Chrisy Schroth (cschroth) wrote :

I (finally) found the same phenomena in our catalog, but I have to go 8 digits past the decimal before it triggers the erroneous call number label. We generally have a policy that our call numbers only go 7 digits past the decimal. In OCLC Connexion, we can get a call number like:
KR
929
.1072042
G226g

on our call number labels. Any more digits than that will not print from Connexion, without falling to a 3rd line of the DDC number portion of the call number. We do have a very few items which we chose to carry out to an 8th digit, to separate genealogy research for different countries. Those we typically print from the catalog with a Zebra printer, or in the long past someone typed it up on a typewriter.
K
929
.10720415
S237f
2017
caused the error you have described
K
929
.
.
.
.
.

5-7 digits past the decimal display/print correctly in our catalog in the Print Labels option. We are on web client 3.2.4.

Remington Steed (rjs7) on 2019-05-06
tags: added: pullrequest
Jane Sandberg (sandbej) wrote :

Thanks for the branch, Adam. I noticed that you changed the permissions on Open-ILS/web/js/ui/default/staff/cat/printlabels/app.js. Is there a specific reason for this? If not, could you please change the permissions back for consistency purposes? Thanks!

Adam Bowling (abowling) wrote :

There was some commenting junk in this that I fixed. It's ready for testing.

(Jane, in the previous iteration, also, there was some Windows permission nonsense rolled in.)

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=8fc3d0746e1b7e17a2e4f9df2c5e69c16a60c1ff

Michele Morgan (mmorgan) on 2019-08-26
Changed in evergreen:
milestone: none → 3.3.4
Chrisy Schroth (cschroth) wrote :

I just tried testing this bug again on this sandbox:
https://bugsquash.mobiusconsortium.org/eg/staff

And it still gives the error when the call number is 8 digits past the decimal. The call number I created is on TCN: 220, and the call number is:
929.10720415
A239t
2009

If I removed the 5 from the end of the call number it generated the label properly, but with the 5 on the end of the first line it gives the dots.

Terran McCanna (tmccanna) wrote :

Chrisy, I don't think Adam's latest patch has been installed on the bug squashing sandbox (unless a request went directly to Blake that I didn't see?) so I would expect to still see the error there.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers