Move calculated dewey ranges/blocks to their own reporting view

Bug #1813191 reported by Jason Boyer on 2019-01-24
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

Eg 3.2.3

One of the few reasons to still use the Classic Item View reporting source is that it has calculated fields for dewey blocks and ranges that can make it very easy to build reports that circ or weeding by subject block(s). Because there aren't really any other benefits to this view those calculated fields should be moved to their own view off of asset.call_number so they're available for use in reporting if needed, but have no effect whatsoever if they're not.

Revision history for this message
Jason Boyer (jboyer) wrote :

Note: Because of some current issues with might_have links in the IDL in web reports the proposed fix (or some equivalent) to bug 1796945 will be required to use this view.

Revision history for this message
Jason Boyer (jboyer) wrote :
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.next
Changed in evergreen:
assignee: nobody → Rogan Hamby (rogan-hamby)
Changed in evergreen:
assignee: Rogan Hamby (rogan-hamby) → nobody
Revision history for this message
Jane Sandberg (sandbej) wrote :

Thanks for this branch, Jason. It will need some brief release notes. Also, will the reporter.asset_call_number_dewey view need to be added to the seed data too, not just the upgrade script?

tags: added: needsreleasenote
Revision history for this message
Jason Boyer (jboyer) wrote :

After far too long I finally return to take care of this. Release note and db build scripts are finally in order in this branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1813191_dewey_reports_rebase / working/user/jboyer/lp1813191_dewey_reports_rebase

Obviously works as expected on Concerto, but if someone would test it against a larger dataset (especially for filtering on these fields) that would be great.

Jason Boyer (jboyer) on 2020-09-01
tags: removed: needsreleasenote
Revision history for this message
Jessica Woolford (jwoolford) wrote :

Not sure if this is a deal breaker since a library who has LC call numbers probably won't be making use of this source, but it does look like it assigned a Dewey Block to LC call numbers in the Concerto data. All else works as expected.

Revision history for this message
Terran McCanna (tmccanna) wrote :

The only scenario I can think of where that would be an issue if is a library were using both LC and Dewey in the same catalog for some reason... maybe if two libraries merged? Personally, I would consider that too much of a corner case to prevent this from moving forward, but it's not a hill I would die on one way or the other.

Revision history for this message
Jessica Woolford (jwoolford) wrote :

I agree, Terran.

I have tested this code and consent to signing off with my name, Jessica Woolford, and email, <email address hidden>.

tags: added: signedoff
Changed in evergreen:
milestone: 3.next → 3.7-beta
Revision history for this message
Galen Charlton (gmc) wrote :

I ran into a call number (in a real database) that breaks the view if the underlying call number row is referenced: "14.11.01":

select label from asset.call_number where id = XXX;
select * from reporter.asset_call_number_dewey where call_number = XXX;
ERROR: invalid input syntax for type double precision: "14.11.01"

As that would terminate any query that processes a row with such a value, I think more error-guarding is needed.

tags: added: needsrepatch
removed: signedoff
Changed in evergreen:
milestone: 3.7-beta → none
milestone: none → 3.next
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers