Add support for digital bookplates

Bug #1673857 reported by Galen Charlton on 2017-03-17
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

We propose to development a Digital Bookplate feature for Evergreen. This feature will enable both staff and patrons to search for and view information related to a set of items, such as donation and memorial labels, or collection information. This development will create infrastructure for applying labeling information to a set of copies in a group. This data will be searchable by all users of the the OPAC, and its contents will appear in the copy summary table of the OPAC record detail page.

Equinox has been commissioned to write this per the following specification:

http://yeti.esilibrary.com/dev/public/techspecs/digital-bookplates.html

Evergreen master

Galen Charlton (gmc) wrote :

For additional background on the genesis of this development, see http://markmail.org/message/vuwp4duqst6zvthf

Changed in evergreen:
milestone: none → 2.next
Galen Charlton (gmc) wrote :
Download full text (3.3 KiB)

A series of patches is available in the branch user/gmcharlt/lp1673857-copy-tags-and-bookplates in the working/Evergreen repository:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1673857-copy-tags-and-bookplates

The release notes:

Copy Tags and Digital Bookplates
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Copy tags will allow staff to apply custom, pre-defined labels or tags
to copies. Copy tags are searchable in both the staff client and public
catalog. This feature was designed to be used for Digital Bookplates to
attach donation or memorial information to copies, but may be used for
broader purposes to tag items.

Each copy tag can either be publicly-visible or visible only to staff.
Copy tags also have types that can be used for restricting catalog
searches on copy tags to particular types.

Copy tags are displayed in the copy table in the record summary page in
the public catalog, and a new library setting can be used to add
a "Digital Bookplate" search field. Copy tags can also be used
as a search filter, e.g.,

  * `copy_tag(bookplate, jane smith)`: search for records that have a
    copy tag of type `bookplate` whose value contains `jane smith`.
  * `copy_tag(*, jane smith)`: search for records that have a
    copy tag of any type whose value contains `jane smith`.

All staff-side interfaces related to copy tags exist only in the web
staff client. There are two new administration interfaces for managing
copy tags and copy tag types. The copy editor now has a `Copy Tags`
button for applying copy tags to copies; that interface can also be
used to create new copy tags on the fly. Furthermore, the copy buckets
interface now has an `Apply Tags` action for assigning tags to groups
of copies.

Permissions
+++++++++++

Two new permission are included:

  * `ADMIN_COPY_TAG_TYPES`: required to create a new tag type under
     Server Administration->Copy Tag Types
  * `ADMIN_COPY_TAG`: required to create a new tag under
    Local Administration->Copy Tags

The existing permission `UPDATE_COPY` controls whether or not a user
can link copies to tags.

Library Settings
++++++++++++++++
A new library setting, "Enable Digital Bookplate Search", controls
whether to display a "Digital Bookplate" field in the search index
drop-downs in the catalog. A "Digital Bookplate" search will include
all records that have a copy that matches the tag specified by the user.
It should be noted that this library settings does not affect the
display of copy tags on the catalog record summary page.

A test plan:

    [1] In Server Admnistration -> Copy Tag Types, test creating
        and modifying copy tag types.
    [2] In Server Admnistration -> Copy Tags, test creating
        and modifying copy tags.
    [3] In the volume/copy editor, test use of the 'Copy Tags'
        button to link or unlink tags from copies.
    [4] In the volume/copy editor, test use of the 'Copy Tags'
        button to create and link new tags on the fly.
    [5] In the copy buckets interface, test use of the 'Apply Tags'
        grid action to link tags to copies.
    [6] In the catalog, test the copy_tag(type, search) and
        copy_tag(*, sea...

Read more...

Changed in evergreen:
milestone: 3.next → 3.0-alpha
tags: added: pullrequest
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
assignee: nobody → Josh Stompro (u-launchpad-stompro-org)

I've got this loaded and will plan on testing it next week. So far I ran into a minor merge conflict when cherry-picking to master with the seed values but otherwise I've seen no issues loading it.

I've been trying to think of what other use case might be served by tagging individual copies but I'm struggling. Other than who funded purchasing the copy, why would I want to tag a specific copy? I'm just trying to think of other ways to promote this feature.

Also, would be beneficial to link the tag display in the detailed record view to a query for that tag. Just to make it easy for someone to see all titles/copies with that tag.

I'm wondering what the best workflow would be for using this for Acq staff. Would some sort of fund integration be worth looking into. You receive a donation of X dollars, you put that money in a new fund. You associate that fund with a tag, so any copies purchased in full or partially by that money get automatically marked with the tag. Then the tag could also somehow alert staff that a book plate is also needed when the item gets processed.

Josh

The tag label display uses a css class of copy_tag_value, which inherits a "white-space: nowrap" setting from rdetails_status td. So if a long tag value gets entered it adds a horizontal scroll bar to the page. Maybe td.copy_tag should have white-space:normal set so the tag values can wrap.

Josh

I just noticed an annoying interaction with the chrome autocomplete when it comes to looking up the tag labels when in the apply copy tags screens.

The browser is remembering values I typed in when I created the tags, and then offering those up in a box the pops over the type ahead output. It makes it impossible to use the arrow keys to choose from the different options that the form displays. This could be annoying. In my testing with Chrome adding a autocomplete=off to the input tag works to keep chrome from trying to fill in values, and lets the typeahead feature take over.

Josh

Dan Scott (denials) wrote :

Josh, the commit Kathy Lussier links in #1486451 would remove "white-space: nowrap" from rdetails_status td - two birds with one stone!

Signoff branch at - user/stompro/lp1673857-copy-tags-and-bookplates-signoff
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1673857-copy-tags-and-bookplates-signoff

Testing Notes: I didn't find any major issues. I added an extra commit to add the autocomplete="off" to the tag input box when linking/creating tags.

[1] In Server Administration -> Copy Tag Types, test creating and modifying copy tag types.
  As a superuser I had no trouble adding/removing/editing copy tag types. When I switched to a user without the correct permission, I wasn't able to add/edit/delete the copy tag types. I did notice that there is no feedback given when the actions failed. The only way to know that it didn't work is because no new entry showed up in the list(when adding types). It would be helpful for there to be an error message. Once I added the correct permissions to the user, then I was able to admin the copy tags.

[2] In Server Administration -> Copy Tags, test creating and modifying copy tags.
  Worked fine, other than the lack of feedback when actions failed.

[3] In the volume/copy editor, test use of the 'Copy Tags' button to link or unlink tags from copies.
  I noticed that the sort for the tag types is case sensitive, which could cause issues if the types are entered with different case standards. "Alpha b" comes before "alpha a".
  The tag types don't seem to be scoped, all of them are shown no mater what the tag type owner is set to.
  The tags seemed to be scoped, those outside of my scope didn't show up in the typeahead search. I was only shown tags with tag ownership that matched my search library settings, even if the copy itself was visible. So if I apply a tag that is owned by CONS to a copy at BR1, and then change my search scope to BR1, I won't be shown the tag in the detailed view.

[4] In the volume/copy editor, test use of the 'Copy Tags' button to create and link new tags on the fly.
  This seemed to work fine. If I didn't have the correct permissions to add tags then the add tag button just silently fails which might cause some help tickets to be filed.

[5] In the copy buckets interface, test use of the 'Apply Tags' grid action to link tags to copies.
  This worked for me. I don't like the lack of feedback though. There is nothing that says - applied tags to x copies, or something like that.

[6] In the catalog, test the copy_tag(type, search) and copy_tag(*, search) filters. Verify that tag visibility (as controlled by the "public" flag on a copy tag) is respected.
  This worked as described.

[7] In the catalog, test the display of copy tags in the copy table on the record summary page.
  I didn't see any problem with that. Long tag labels can cause problems but there is another bug where that is going to be addressed.

[8] Test the opac.search.enable_bookplate_search library setting and verify that it causes a 'Digital Bookplates' search option to be added.
  The 'Digital Bookplates' search option shows up when the library setting is applied and goes away when it is removed. If I set the setting for one branch, it only shows up when searching that branch only.

tags: added: signedoff
Changed in evergreen:
assignee: Josh Stompro (u-launchpad-stompro-org) → nobody
status: New → Confirmed
Galen Charlton (gmc) on 2017-07-24
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

Thanks for the testing and feedback, Josh! I've pushed this to master, and will open a couple LP reports regarding making the UI provide additional feedback.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Galen Charlton (gmc) → nobody
Galen Charlton (gmc) wrote :
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers