Evergreen

Acq: Move holdings subfields to admin pages

Bug #2019425 reported by Tiffany Little
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

Bug Description

Wishlist.

Currently acquisitions holdings subfields are defined per-provider, and they need to be created each time you create a new provider. In PINES at least, we use the same holdings subfields and holdings tag across the entire consortium. So it's just extra work to create for each new provider, and admittedly, I often forget until someone's upload is missing holdings. (Oops.)

I've never found holdings subfields needed to be on a per-provider basis; usually we tell providers what our standards are and that's how they configure it for us.

So it would make more sense to me to have Holdings Subfields as an acq admin page, and include an org filter. So providers at the same or below org would use holdings subfields defined in the admin page.

And/or we could have them in an admin page, and then on the main Providers creation modal have a dropdown where you select a set of holdings subfields. Kind of similar to a matchset or a distribution formula? This seems like it might solve the problem if someone accidentally created multiple sets of holdings subfields at an org; if that happened then vandelay wouldn't know which to choose.

Even if we have a dropdown on the Providers creation modal to choose a holdings subfield set, that seems way less work than having to create each individual subfields for each provider.

Tags: acq acq-admin
Revision history for this message
Galen Charlton (gmc) wrote :

Noting that this would require refactoring the database schema to establish the notion of an acquisitions holdings subfield mapping independent of the provider record. Something like:

acq.holdings_subfield_map
  id
  owner
  name (for the map)

acq.holdings_subfield_map_entries
  id
  field_name
  subfield
  holdings_subfield_map FK

Then acq.provider would gain a holdings_subfield_map column.

During upgrade, it would be possible to migrate the existing mappings to a de-duplicated set linked back to the correct providers.

Maybe toss in a library setting to specify a default mapping for new provider records.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

We also generally use the same holdings subfields across our consortium. (I think it's the same for all but since libraries can set them up for their providers I'd have to check to be sure.)

I like the idea of subfields working like match sets where you can pick the one that applies to your provider. Then we could set up one (or possible a few) at the consortium level and libraries could pick the one that applied. This would be especially helpful if you have a provider that requires a different subfield than your standard, so you could easily set it up as an alternative to be used with that provider.

Revision history for this message
Christine Morgan (cmorgan-z) wrote :

We also use the same holdings subfields across out consortium.
+1 to the idea of subfields working more like match sets.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.