Workaround for not being able to request after a keyword search in Sierra 3.0's opac

bib_display.html

<script src="https://code.jquery.com/jquery-1.12.4.min.js" integrity="sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ=" crossorigin="anonymous"></script>
<script>
  "use strict"

  /*
    Copyright 2017 Jim Nicholls, The University of Sydney.

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
  */

  // Workaround for bug introduced by Sierra 3.0.
  jQuery(function($) {

    (function () {
      var searchInfo = getSearchInfo();
      if (!searchInfo || searchInfo.searchType !== 'X') {
        return;
      }
      var requestButton = getRequestButton();
      if (!requestButton) {
        return;
      }
      var bib =
        findBibNumberInRequstButton(requestButton) ||
        findBibNumberInOtherButtons() ||
        findBibNumberInBibRecordLinks();
      if (!bib) {
        console.log("Couldn't get the bib record number from anywhere, so can't re-write the request buttons's url.");
        return;
      }
      requestButton.href = constructBibRecordRequestUrl(searchInfo, bib);
      console.log("Re-wrote the request button's url.");
    })();

    function constructBibRecordRequestUrl(searchInfo, bib) {
      return '/search' + searchInfo.scope + '?/.' + bib + '/.' + bib + '/' + searchInfo.commaJank + '/request~' + bib;
    }

    function getRequestButton() {
      var c = $('a[href*="/search"][href*="/request"]');
      return c && c[0];
    }

    function getSearchInfo() {
      var m = window.location.href.match(/\/search(~S\d)?\?\/(.).*\/([A-Z0-9]+(%2C[A-Z0-9]+)+)\//);
      if (m === null) { return; }
      return {
        'scope': m[1] || '',
        'searchType': m[2],
        'commaJank': m[3]
      };
    }

    function findBibNumberInBibRecordLinks() {
      var r;
      $('.bibRecordLink, #bibRecordLink').each(function () {
        var m = this.innerHTML.match(/\/record=(b\d+)/);
        r = m && m[1];
        return !m;
      });
      return r;
    }

    function findBibNumberInOtherButtons() {
      var r;
      $('a[href*="save=b"]').each(function () {
        var m = this.href.match(/save=(b\d+)+/);
        r = m && m[1];
        return !m;
      });
      return r;
    }

    // If the patron is logged in, the bib number is NOT in the request button's url.
    function findBibNumberInRequstButton(requestButton) {
      var m = requestButton.href.match(/\/request~(b\d+)/)
      return m && m[1];
    }

  });

</script>

Use of this code is at your own risk.

What is this Gist?

A bug was introduced in Sierra 3.0 where patrons cannot successfully request after doing a keyword search. They can after doing another search, such as title or call number. This seems to only affect Sierra sites using request circles.

This is a workaround so that patrons are not affected by this bug. This is not a fix! It just masks the bug.

How do I use this Gist?

Add this script towards the bottom of bib_display.html.

The code uses jQuery. As it is here in this gist, it gets jQuery for their content delivery network (CDN). If you already have jQuery in your bib_display.html, leave out the first script tag.

What does this Gist do?

This code checks the url to detect if the patron has done a keyword search. If they have, it locates the request button — if it there is one — and rewrites the url of the request button. It changes the url to look like the patron just did a record number search, instead of a keyword search. This avoids the bug.

Are there any side effects?

Because the request button's url is rewritten, after completing a request the patron may not be where they might expect to be. They will be back at the record they just requested, but their search will show as a record number search and not as their keyword search.

Will this work for me?

It might. It going to depend on how different your bib_display.html is from The University of Sydney's bib_display.html.

Also this only fixes the request button in bib_display.html. If you have request buttons elsewhere, such as briefcit.html, requesting via those buttons will still not work.

Does this work across all browsers?

It has been tested on:

• Windows 10
  • Microsoft Edge 38
  • Internet Explorer 11
• macOS Sierra
  • Chrome 56
  • Firefox 51
  • Safari 10
• iOS 10.3 public beta 2
  • Chrome 56
  • Safari
• Android 7.1.1
  • Chrome 55

Why not do the workaround in pverify3_web.html?

Actually, this is where I started trying to code the workaround. Putting the workaround here would have meant any request button would work, not just the request button on bib_display.html.

The problem I faced is that when doing the workaround in pverify3_web.html, I can only get the bib record number from the request url.

Inexplicably, when a patron is already logged in, Sierra doesn't include the bib record number in the request url. 😖

The University of Sydney doesn't have request buttons outside of bib_display.html, so I went with a workaround in bib_display.html. Otherwise I would have need some kind of fallback for when a patron is already logged in.