Default record match set in Vandelay

Bug #1067087 reported by Jeff Davis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

It would be nice if you could define a default Record Match Set when importing MARC records with Vandelay.

I've got a patch that lets you do this via a new org unit setting:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/vl-default-match-set

You enter a text string as the setting value, and if that string matches the name of an option in the Record Match Set dropdown, that option is selected as the default when the Vandelay import screen loads. It's a bit crude, but it works.

tags: added: wishlist
Dan Wells (dbw2)
Changed in evergreen:
importance: Undecided → Wishlist
Revision history for this message
Bill Erickson (berick) wrote :

This is a good start, but I'd recommend changing the org setting datatype to "link" and the fm_class to "vms". This will magically give staff a drop-down of match sets to select from in the org settings interface. It will then store the ID of the match set instead of the name, which is not guaranteed to be universally unique.

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :
Changed in evergreen:
status: New → Triaged
Revision history for this message
Ben Shum (bshum) wrote :

Should probably add something to the next releasenotes for this bug.

Changed in evergreen:
milestone: none → 2.4.0-alpha
tags: added: needsreleasenote
removed: wishlist
Revision history for this message
Ben Shum (bshum) wrote :

That said, tested and worked for me to add a default match set for vandelay importing.

Sign-off in branch: working/user/bshum/vandelay-default-match-set

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/vandelay-default-match-set

Changed in evergreen:
status: Triaged → Confirmed
Revision history for this message
Ben Shum (bshum) wrote :

Actually the more I think about this feature, the more I think this might be better served as some sort of workstation / login decision for individual users to decide which default match set they like to have.

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

If you have organizational policy around what match points to use when importing records (as we do, to help standardize management of a common set of MARC records and to reduce the number of duplicate records), it is helpful to be able to define a common default for all users. If it was a workstation or user setting instead, we would just end up having to ask all staff to set the appropriate default match set manually in their staff client.

Revision history for this message
Kathy Lussier (klussier) wrote :

In our case, we do have situations where a default match set would come in handy. In one consortium, we have libraries that do their own Vandelay uploads, and, in those cases we would want a default match set to appear so that they don't forget to apply it or accidentally select the wrong match set. In fact, it would be nice if other options on this screen could also come with a default.

However, I also see Ben's point as well also have central cataloging in all of our consortia. In this environment, the staff are likely to be working with different match sets. Even at the same workstation, you may see one staff member doing uploads that utilize different match sets. Rather than a workstation default, in this situation, I think it might be more useful to have Vandelay profiles that bring together different defaults. For example, you might have an ebook profile that identifies a specific match set along with a merge profile that adds the 856 field. An OCLC upload profile use a different match set and merge profile, while a profile used for importing records for a new library that has joined the consortium might be entirely different from the other two.

For now, though, I think this patch will be very useful for some of the scenarios our users face. I've added a commit for a release notes entry and signed off at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/vandelay-default-match-set

Revision history for this message
Ben Shum (bshum) wrote :

I was working on getting this committed and then realized that the branch didn't include any change to the stock schema.

Signing off on kmlussier's release notes commit and then adding another commit for the schema change itself in:

working/user/bshum/vandelay-default-match-set2

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/vandelay-default-match-set2

Some questions while we test that:

- should we have a better description of the org unit setting included in the schema change / upgrade bits?
- should we drop the leading "Vandelay: " from the setting's name as repetitive, given that the group for Vandelay is being used?
- are there any other settings that might need moving into the new Vandelay group?

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

Just my answers to bshum's questions:

- should we have a better description of the org unit setting included in the schema change / upgrade bits?

Probably. Simply repeating the label is not necessarily a good idea.

- should we drop the leading "Vandelay: " from the setting's name as repetitive, given that the group for Vandelay is being used?

Yes.

- are there any other settings that might need moving into the new Vandelay group?

Maybe, but that should be the subject of another LP bug.

Revision history for this message
Mike Rylander (mrylander) wrote :

I've committed this to master for 2.4 after removing the "Vandelay:" prefix from the seed data labels.

Changed in evergreen:
status: Confirmed → 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.