Owning lib of asset.copy_location not visible in Item Attributes Editor UI

Bug #778989 reported by Chris Sharp
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
2.6
Fix Released
Undecided
Unassigned
2.7
Fix Released
Undecided
Unassigned

Bug Description

The owning library of the copy location of an item is not visible in the Item Attributes Editor. This leads to misassignment of copy locations with no way of knowing that a cataloger is doing so. This occurs in library systems that apply a consistent copy location naming scheme across all member units (e.g., all CHRL libraries use the name "ADULT" for a copy location in each of their libraries) and where items are cataloged centrally. A cataloger will set up an Item Attributes Editor template which applies an "ADULT" copy location for one of the system's branches, then re-use that template for other branches' items, not realizing that the "ADULT" location she/he is using belongs to a specific branch.

Workarounds would be to have catalogers manage a large set of templates that factor in copy location owning lib (which is actually quite unwieldy, workflow-wise) or to run a periodic SQL-level cleanup that tags asset.copy objects with the correct location.

What would be most desirable is if the system would know to set the correct copy location by name (which would allow catalogers to retain existing templates - recreating templates would be a very burdensome task). Basically, Evergreen should "know" that catalogers want the asset.copy.circ_lib to be the same as asset.copy_location.owning_lib.

Thanks,

Chris

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Please supply at minimum, what version of Evergreen you are on.

Changed in evergreen:
status: New → Incomplete
Revision history for this message
Chris Sharp (chrissharp123) wrote :

This is on 1.6.1.8 on Debian lenny, OpenSRF 1.6.3, and Postgres 8.4.

Changed in evergreen:
status: Incomplete → New
Revision history for this message
Thomas Berezansky (tsbere) wrote :

I throw this out as a possible solution.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/correct_copy_location

If others agree someone should add a pullrequest tag here.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

I'll take a look when I get a chance and maybe target this, sign off, and possibly backport it. Probably not until tomorrow, though.

Changed in evergreen:
status: New → In Progress
assignee: nobody → Jason Stephenson (jstephenson)
Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → Thomas Berezansky (tsbere)
Revision history for this message
Jason Stephenson (jstephenson) wrote :

Thomas,

I forget why you asked me to give this one to you. Are you working on this or do you consider the branch done?

Jason S.

Revision history for this message
Jo-Anne Teeuwsen (jteeuwsen) wrote :

This has become more of an issue now that we can filter by shelving location on the advanced search page. Mismatched copy and owning locations result in incomplete search results for individual shelving locations.

Changed in evergreen:
milestone: none → 2.next
importance: Undecided → Medium
Revision history for this message
Chris Sharp (chrissharp123) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: Thomas Berezansky (tsbere) → nobody
Kathy Lussier (klussier)
tags: added: signedoff
Changed in evergreen:
status: In Progress → Confirmed
Revision history for this message
Ben Shum (bshum) wrote :

Since Kathy and Chris suggested in IRC this was to be a bug fix, targeting to appropriate new milestones and pushing to supported release series rel_2_7 and rel_2_6 as well as master.

Thanks all, and set!

Changed in evergreen:
milestone: 2.next → 2.7.2
status: Confirmed → Fix Committed
Galen Charlton (gmc)
Changed in evergreen:
milestone: 2.7.2 → 2.next
Revision history for this message
Ben Shum (bshum) wrote :

Removing 2.next top level milestone, since this was a bug fix that was repaired in an actual series maintenance release.

Changed in evergreen:
status: Fix Committed → Fix Released
milestone: 2.next → none
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.