call number label class not able to be set in 2.0, default is ignored

Bug #787150 reported by Dan Wells
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Dan Scott

Bug Description

Evergreen 2.0 added a label_class column to the call number table with one major purpose being the generation of correct sort keys. You can also specify a default label class as an org unit setting. However:

1) There are no interface elements for setting the label class of an individual call number.
2) The default setting is not consulted (that is, not set in the call number table) when new call numbers are created.

These two facts together greatly reduce the utility of this very valuable feature, as all new call numbers end up in the 'Generic' class.

While #1 has been addressed in 2.1+, there is still work to be done in setting this class on import. Also, which interface parts (if any) make it back to 2.0 is subject to debate.

As a more reasonable default, I suggest something similar to the attached patch be applied to master, 2.1, and 2.0. Rather than always defaulting to '1' (Generic), it defaults to the 'cat.default_classification_scheme' setting for the owning_lib org unit, if set.

Thoughts?

Thanks,
Dan

Revision history for this message
Dan Wells (dbw2) wrote :
Revision history for this message
Dan Scott (denials) wrote :

I think it looks good! I intended to do something like this as a next step ages ago, but my lack of focus meant that the next step never happened. I think you've nailed it. If you push it to a working branch, then I'll gladly sign off on it.

Revision history for this message
Dan Wells (dbw2) wrote :

Thanks Dan.

Patch for master is pushed to user/dbwells/lp-787150

Patch for rel_2_x is pushed to user/dbwells/lp-787150_rel_2_1

I don't know if doing these branches this way was the right or smart way to do it, but I am hoping you can now cherry-pick these without issue.

Merge away!

Revision history for this message
Dan Scott (denials) wrote :

Sweet. I reformatted the commit message to wrap at less than 80 chars per line (and made the first line closer to 60 chars, per git conventions), as well as wrapping the long SQL line over 4 lines instead.

IRC also pointed me to Open-ILS/src/sql/Pg/made-db-patch.pl to avoid upgrade numbers, as 0540 had already been committed by the time I was able to test out your patch and sign off on it, so I had to bump the version to 0541. made-db-patch.pl should help avoid that in the future.

The important part is that your code WORKED! Thanks so much; committed to trunk in 047e3586f757038e8e0c29b9d78f8191ae9d1683

Revision history for this message
Dan Scott (denials) wrote :

Backported to rel_2_1 and rel_2_0 as well (with one more patch to fix the config.upgrade_log INSERT statement - my error on that part). Thanks so much for correcting this flaw, Dan!

Changed in evergreen:
assignee: nobody → Dan Scott (denials)
importance: Undecided → High
status: New → Fix Committed
Ben Shum (bshum)
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.