Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
minLevel1
maxLevel6
outlinefalse
styledefault
typelist
printabletrue

Outstanding Issues

Resolved Issues

Deep search configurations for Seneca

Loyalist is

Query to patron letters

  • the Type_6_header label is missing in the Values where labels are to be configured for the Query to Patron Letter

  • OCLS and St Lawrence have opened cases with Ex Libris

  • September 27: issue seems to have been resolved for Conestoga

    • the following code is in the label for Type_6_subject = Regarding Your Article Request – Complete Form %reqId%

Borrowing Requests - Seneca

  • colleges are unable to send borrowing requests to Seneca

  • OCLS has opened a case with Ex Libris

  • and Conestoga both noticed this issue with their letters: https://clo-collaboration-spaces.atlassian.net/wiki/x/FoB2Yw

  • Ex Libris Development has fixed your issue regarding the query_6 display issue and you should see the fix with the April 2025 release.

  • They advised that as a workaround you can fill in the XSL. Instead of '@@Type_6_header@@' you can add any other text.

Deep search configurations for Seneca

  • Loyalist was unable to search Seneca’s catalogue using their deep search configurations

  • the local search profile P_NH_SY was not defined as a search slot in the view configuration for the view that Seneca is able to search Loyalist, the NZ OCLS has opened a case with Ex Libris College provided access to through the Primo VE Deep Search Configuration; the issue was resolved after Seneca adjusted the configurations for their view and search profile

Borrowing Requests - Seneca

  • colleges were unable to send borrowing requests to Seneca

  • a trailing space in the Partner information for Seneca, on the Parameters tab, the server information (na02.alma.exlibrisgroup.com) was causing issues with the delivery of ISO messages. Updating that field in the NZ and distributing the update resolved the issue.

  • Fleming and Conestoga successfully tested sending borrowing requests and completing the request process with Seneca

Using Blank ILL form to create requests is allowing items available at our institution to be requested through resource sharing

Summary of issue from Ex Libris ticket opened by Loyalist College:

We are not part of a consortium, so we are only able to search our institution for titles in Primo.
We are using the Blank ILL form in Primo (testing stage), which sends the borrowing request to Alma.
When the "locate" function is run on the borrowing request in Alma, it does not give a warning message that it is owned by the institution.
When a borrowing request is created manually in Alma, and the "locate" function is run, it does provide a warning message that the title is owned by the institution.

We have two "sending borrowing requests rules" - 1. Do not send request automatically - no input parameters, output parameter = False, and 2. Do not send if owned by institution - input parameters "Self-ownership = True, output parameter = False.

Ex Libris Support resolution of the ticket:

Our development team has confirmed that Alma is currently not designed to provide this functionality on the blank ILL form, so the next step is to pursue this as an enhancement.

We strongly recommend that you pursue this enhancement through the ELUNA Product Working Group enhancement voting process. On a periodic basis the ELUNA Alma Product Working Group does an open call for enhancement suggestions that are voted on by the ELUNA Alma user community and presented to Ex Libris Development. This is the best way to have your enhancement request heard. Please see the article linked below with common Q&A's regarding the IGeLU and ELUNA enhancement process.

Ex Libris has also made available sharing ideas directly with our product managers using the Ex Libris Idea Exchange website (http://ideas.exlibrisgroup.com ). We welcome you to sign in to the site and share your ideas with us . Additional information can find on the website’s FAQ.

Here is the article - https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Enhancement_Process_-_Common_QandA

  • Loyalist College has added "view local resources" as a first step in their managing borrowing requests workflow to address this issue

Resource sharing request option appearing in records for electronic resources

  • Colleges can address this partially through Display Logic Rules that hide specific resource types (see sections and by limiting the New_Discovery_Network search profile to physical materials (see sections ;

  • However, some colleges have noticed that requests can still be placed if patrons access the resource from databases outside of Primo VE, through related resources link, bypassing the DLRs: https://clo-collaboration-spaces.atlassian.net/wiki/spaces/RSIP/pages/1369243679/Humber+-+Discussion+Page?focusedCommentId=1513291777; Page 1+ Study Group Session 86 (at approximately 41 minutes); Resource sharing appearing when clicking on "Check for fulltext" in EBSCO databases. These requests for electronic resources should be automatically cancelled in Alma (“cancelled by staff” status) and patrons will receive the Ful Cancel Request letter.

  • DLRs that hide the RS Request Link based on Resource Type are based upon the "recordtype" tag in the Control section of the PNX record for a Primo result. The PNX pulls this information from a record's associated bibliographic information. When this is properly populated in a PNX record, you will see this resource type show up at the very top of a Primo page, right above the resources title (e.g. https://app.screencast.com/3JqKPjqEergnB). But this does rely on the PNX being able to pull information from a full bibliographic record. For Network-catalogued resources, as well as CDI records, this is not an issue. However, it can be a problem with OpenURL records.

When users find an article in a database which then redirects them to a Primo page, this redirection from an outside service/database is done using OpenURL protocol. The problem with that is there's no guarantee that the information sent in the OpenURL will contain all of the necessary information for your DLRs to work as expected. If the service/database sends an OpenURL without a proper resource type, there's no way for Primo (the PNX) to properly populate the recordtype tag, and so the DRL cannot be applied.

You can see this using the example URL: https://humber.primo.exlibrisgroup.com/discovery/openurl?institution=01OCLS_HUMB&vid=01OCLS_HUMB:HUMB&date=20240501&issue=2&isbn=&spage=75&title=Critical%20Education&atitle=Connecting%20the%20Dots%20Between%20Extreme%20Ideologies,%20%22Parent%20Choice,%22%20and%20Education%20Privatization%20in%20Alberta%20and%20Canada.&sid=EBSCO:Education%20Research%20Complete:177504579&volume=15&pages=75-83&issn=19204175&au=Ganshorn,%20Heather&genre=article&ID=doi:10.14288%2Fce.v15i2.186885

First, add &displayCTO=true to the end of the URL, and then load the page again. Once you do, you'll see the button to Display CTO. Clicking on this will open a new tab with the CTO information, which will include a PNX section. If you review this section in the above link, you'll see that the recordtype tag has "bibliographic" for a value, which does not match what's configured in the DLR. This means that the RS Request link will appear for this OpenURL-generated record.

Meanwhile, compare that to the same article but if it was discovered via Expanded Search Results when searching directly in Primo: https://humber.primo.exlibrisgroup.com/discovery/fulldisplay?docid=cdi_erudit_primary_1111308ar&context=PC&vid=01OCLS_HUMB:HUMB&lang=en&search_scope=MyInst_and_CI&adaptor=Primo%20Central&tab=Everything&query=any,contains,Connecting%20the%20Dots%20Between%20Extreme%20Ideologies,%20%22Parent%20Choice,%22%20and%20Education%20Privatization%20in%20Alberta%20and%20Canada.&pcAvailability=true

When searched for in Primo, this instead pulls up the CDI record (instead of the OpenURL). Because it's CDI, the PNX can properly apply the record type and the DLR will work as designed. You can see this by adding &showPnx=true to the end of the URL for the CDI record.

In summary: this is an unfortunate situation that can arise when working with Primo records generated via OpenURLs. Primo and the Link Resolver can only work with the information provided in the OpenURL, so if that information is inadequate it can lead to this occasional request that "slip through the cracks."

Alma currently lacks a direct method to prevent Resource Sharing Requests on OpenURL-generated records.

...

Cancel request on locate failure

  • Loyalist College has been testing disabling Cancel Request on Locate Failure in their borrowing setup because it was sending the request cancellation letter very quickly to patrons and Loyalist is not ready to disable the letter

  • They found that:

    • Borrowing requests with a 'locate failed' status remained in their active borrowing requests and they could review and place the request externally. The Requester does not receive a Request cancelled letter. They are satisfied with this functionality.

    • However, the request with "locate failed" status was only showing a "View" option and Cancel is not available in the row action menu.  Staff can click on the specific request and select "change status" under the ellipsis (...) action menu. It allows them to select "change status" and "Cancelled by staff > Reason: Failed to locate potential suppliers".  However, the job does not make any changes (0 or 1 changes applied).

    • They can also "remove the request" and monitor the "failed to locate" requests in analytics.

Issue was resolved: Loyalist was able to cancel a few "locate failed" requests and is happy with this setting for Loyalist.

https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/050Resource_Sharing/020Borrowing_Requests/030Managing_Resource_Sharing_Borrowing_Requests

 

...