Primo VE Known Issues - Not updated as of August 2022

 

Issue

Description of Issue

Status w/ExL

Campuses Reporting

Issue

Description of Issue

Status w/ExL

Campuses Reporting

# of results not displaying for facets using EBSCO

SJSU is not seeing # of results for Resource Type facet, subject facet, database facet, etc.when searching in the SJSU collections (My Inst and CDI and EBSCO API). We added the EBSCO API to this search profile yesterday. What needs to be done to correct this?

See {+}https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/040Search_Configurations/010Configuring_Search_Profiles_for_Primo_VE+ under the "Details Fields for Other Searches" heading:
The EBSCOhost API does not support the following:
Starts with option for title searches. The API will return all results, not just the titles that start with the search term.
Pre-limiting the search by language.
Facet record counts. When searching in a scope that includes the EBSCOhost API, none of the facets will have record counts.

SJSU

Appearing-Disappearing Held by Library facet

Intermittent situation where Held by Library facet randomly appears while searching in VE. It happens with both of our current search slots (one is DN+CDI, the other is NZ physical + local E + CDI). The appearance/disappearance of the facet happens during switches between search slots, between simple and advanced, and when starting a new search, but it is completely unpredictable and random.
Sometimes Held by Library shows up immediately and sticks around for the entire search session. Sometimes it never appears. Sometimes it comes and goes during the session.
Library and Location facets also disappear/reappear.

Salesforce case 00936448 created - fix planned for Q3 2021

 

Fix planned for Jul release, might be in Aug.

Update: Fixed in August release.

SLO, Northridge, likely others

Available for "Held by library" facet does not limit results down to what is physically held by institution but rather includes inventory from other CSU libraries

On traditional Primo, we've always been able to do a search that included the physical inventory of all campuses, and then use a top level facet to limit to materials available only in our specific institution library.
It was my expectation that "Held by library" would have the same effect, faceting the results to items that were indeed "held by my library" but strangely enough, it has no apparent effect whatsoever other than removing CDI results.
Is this expected behavior?
If this is expected behavior, that "held by library" actually means "held by discovery network" this is problematic. Institutions like mine, who have long since settled on a Google-esque single search of all scopes (no confusing drop-downs) have no out of the box way for users to facet to local items only. At other institutions, users searching in the discovery network (often renamed to "CSU+" or similar) cannot easily toggle back and forth between all results and local results, and are forced to redo the search.
I suspect this behavior might have a particularly major impact on a system like ours where users on a short deadline are not interested in books that take 3 days to arrive, or in driving to another campus that is 500 miles away.
Again, if this is expected behavior, can Ex Libris suggest a way to create a custom top level facet that will enable us to keep the Discovery Network (or at least its physical items) in our default search slot, but let our users limit to just local items?

The Availability facet values cannot be adjusted, but you can enable the Institution facet and push it up the page to just below the Availability facet.
Not directly related to your question, but here is some documentation on the different options of Library facet for NZ scopes:

https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/Collaborative_Networks/0200Display_Functionality#Brief_Results_Display_Settings

SLO

Broken Saved Search RSS Feeds

we use RSS feeds from saved searches to power new book lists. After the upgrade the RSS feeds resolve once (or not at all) and then will no longer return results.

Example Saved Search: https://csu-sdsu.primo.exlibrisgroup.com/discovery/search?facet=rtype,exclude,government_documents&facet=newrecords,include,30%20days%20back&facet=rtype,include,books&mode=advanced&offset=0&query=sub,contains,Communication,AND&search_scope=MyInst_and_CI&sortby=rank&tab=Everything&vid=01CALS_SDL:01CALS_SDL

RSS Feed: https://csu-sdsu.primo.exlibrisgroup.com/primaws/rest/priv/savedSearches/addRss?rssId=11539769480002917&queryTerm=Communication&vid=01CALS_SDL:01CALS_SDL&ver=2_1_4

Note that there is a known issue with RSS feeds and you must change the last bit "&ver=2_1_4" to "&ver=2_1_4" - but even after doing this the feed fails to return results.

https://csu-sdsu.primo.exlibrisgroup.com/primaws/rest/priv/savedSearches/addRss?rssId=11539769480002917&queryTerm=Communication&vid=01CALS_SDL:01CALS_SDL&ver=2_1_4

this is the expected behavior. The idea behind RSS is bringing the new records added since the last time it was run. So, once it's invoked and brought the new records, and you copy the link and paste is in a browser, you're actually asking for the records that were added since the last run (that was a minute ago), and hence you get no results.
In Classic Primo there is a flow that allows (in a fictive way) the use of a special database table that stores the RSS results, so that you can get the same results each time you run the link throughout the day.
This is currently not supported in Primo VE. You are welcome to pursue this as an enhancement request.

 

Browse Search Redirects?

Is there a way to automatically redirect browse searches in Primo to browse searches in Primo VE?

We have hundreds of LibGuide references with links like this:

https://csus-primo.hosted.exlibrisgroup.com/primo-explore/browse?vid=01CALS_USL&browseQuery=Greek%20Americans&browseScope=subject&innerPnxIndex=-1&numOfUsedTerms=-1&fn=BrowseSearch

They do not resolve.

 

The system cannot redirect browse search ULRs.
It may be possible to locally implement a redirect using JavaScript, although my attempts so far haven't been fruitful.

Not sure if you already figured out the change in the syntax but it looks like the equivalent of that link in Primo VE is this:
https://csu-csus.primo.exlibrisgroup.com/discovery/browse?vid=01CALS_USL:01CALS_USL&browseQuery=Greek%20Americans&browseScope=subject.1&innerPnxIndex=-1&numOfUsedTerms=-1&fn=BrowseSearch

The browseScope is now "subject.1" instead of "subject".

Maybe you already knew this and were hoping for a redirect but this may help if a redirect is not available.

In addition to replacing
/primo-explore/
with
/discovery/
the browseScope value would have to be adjusted, as you already noticed. the VID must also be changed from 01CALS_instcode to 01CALS_instcode:01CALS_instcode.

 

Browse Search Results

One of our library users reported inconsistent behavior with the browse search:

When I browse for the subject Kazantzakis, several results come up above Kazantzakis, Nikos (my intended result). And when I go to page 2 of the results, those top subjects above Kazantzakis are still there before the next Kazantzakis results appear. Also, I don’t think all results are coming up.

 planned to be fixed during Q2 2022

 

Bug in Format field display

San Luis Obispo reported a strange issue with the Format field display on at least one of their records. The MARC record contains "<>" characters in 300 $a which break rendering of the information in VE:

https://csu-calpoly.primo.exlibrisgroup.com/permalink/01CALS_PSU/1pec106/alma991004124389702920

 

There is no norm rule in use with this field - it is configured OOB.

The same record in PBO:

https://cpslo-primo.hosted.exlibrisgroup.com/permalink/f/39e239/01CALS_ALMA71376766480002901

 

Is this a bug or is there some configuration issue at play? 

Indeed, this is a bug.
I've created Salesforce case #00970932 for tracking.

By the way, it is possible to see and edit the OOB norm rules.
Go to: Discovery > Display Configuration > Manage Display and Local Fields > Add Field > Add Display Field > Field to edit = Format > edit MARC21 normalization rule for display.

If you don't mind removing the angle brackets from display (until the defect is resolved), you can replace the OOB rule for MARC 300 with the following:

rule "Primo VE - Format 300" when MARC is "300" then set TEMP"1" to MARC."300" excluding num subfields without sort remove string (TEMP"1","<") remove string (TEMP"1",">") create pnx."display"."format" with TEMP"1" end

 

 

c.uresolver.viewit. appearing in portfolios

A few campuses have noticed an odd display that seems to have appeared after moving to VE.

For those of us who use the "public access model" in the acquisitions tab of a portfolio, when testing in Alma, we now see this (image below).   Luckily the "c.uresolver.viewit." is not appearing in Primo VE.  It does appear in Primo (obviously don't care but sharing this detail).

Here is an example for an ebook in Alma.  It is happening for any portfolio that includes the "public access model."

What do you think is happening? And how can we get this fixed?

 

Perform the following in Alma:
Discovery > Display Configuration > Labels > ViewIt Labels > Add Row,
Code =  c.uresolver.viewit.public_access_model
Description = NOT_DEFINED
Default Value = No

 

Can't enter Ranking Configuration area without error

Not sure how long this has been an issue since I last used this area a few months ago. Can others enter this area without error or have you updated it recently?

I entered the table here: Configuration Menu > Discovery > Search Configuration > Ranking Configuration
and tried to add a resource type for the first time (Videocassette = 0.01). I got the Oops error so I left the area. Once I came back, now I get the error all the time without doing anything. It also updated the time I last changed the Boost My Institution ranking but I didn't touch that field.

 

This is being analyzed in Case 00974581 by Primo 2nd line Support.

 

Update: Thanks for that information. It appears that the problem is caused by the fact that there is a local resource type defined in the NZ for videocassette, but not in the IZ. Because that resource type is defined in the NZ and some of your records have that type, you are able to select it from the list of resource types in the ranking configuration page. But then, when the system tries to display the resource type boosting, an error occurs because that resource type is not defined in the IZ.

When I go to Configuration > Discovery > Local Resource Types, I see that you have no local resource types defined. According to the attached documentation about local resource types:
"For consortia, local resource types must be defined in both the IZ and NZ when IZ records are linked to the NZ."

So, it's necessary to have the local resource types defined in both 01CALS_NETWORK and 01CALS_UNO. If you add the local resource type of videocassette to your IZ, then the error you see in the ranking configuration should no longer occur.

Can you try adding the videocassette local resource type to your IZ? For your reference, here is how it is defined in the NZ: https://www.screencast.com/t/EM1l4OLc

Once you have defined the videocassette local resource type, if you go back to the Ranking Configuration, you should see the setting you created yesterday for videocassette and no error.

 

CDI Scope question

The Central Discovery Index (CDI) consists of more items than articles, and we want to keep a variety of items turned on in CDI. All of these items and formats are available in our “everything” scope. We also have a need to just search for Articles. 

In our current instance of Primo, we made a work around by filtering the search results to be limited to “articles.

In Primo VE, is there going to be a better way to do this? Will it be possible to have a scope which only searches articles from the CDI? 

I don't see any current plans to develop such an option for CDI search.

 

Citation linker redirect

Is the URL for the Primo BO citation linker supposed to redirect to the one for VE?

Citation Linker URLs don't redirect.

 

Configuration for Request this item

We want to edit the content of the "Request this item" box (example record permalink: https://csu-chico.primo.exlibrisgroup.com/permalink/01CALS_CHI/bbjidc/cdi_gale_healthsolutions_A606636759 ) to match the box in our Primo. Where is this box configured? an example from CSUN. I found the labels eventually except for the equivalent of c.uresolver.getit2.holding_list.empty.guest_user = Sign in, and you'll see a link to request the item.
But we are also not getting these new labels to show up and we are missing the Check Holdings at Other Campuses that we should be seeing in the same area.

This text is configured in the Discovery Interface Labels code table for Primo, and in the ViewIt Labels code table for VE.
In Primo, you're getting a Get It window, as opposed to a How to Get It window in VE.
There is an issue where some labels from the ViewIt Labels table don't display in VE. I see it was decided about a year ago not to include a fix for this in the VE roadmap. I'll get VE Dev. and Product Management to reevaluate the matter.Salesforce ticket created 00950168 for tracking.Update: Ben doesn't see a way to work around the current display of VE's 'How to Get It'.
I've bumped VE Development for a response.
Update: A fix for this issue has been scheduled for Q4 2021.

Northridge, Chico, probably all

Customized Public Notes

We have local customized public notes for our campus firm purchased ebooks to indicate one-user, three-user, or unlimited-user access models.    The public note HTML code didn't migrate correctly.   

Here is what it looks correctly in Classic Primo:

 

Here is what it looks like in Primo VE.  It displays HTML code instead of "Three users at a time".

We have thousands of local ebooks with such notes.  Is there any way we can correct this globally?

Further updates will be provided in Case 00937205 and 00976180.

Until this gap is dealt with by VE development, you can edit each Access Model and remove the HTML code.
You might find this useful. Alma Support will check whether Access Model public notes can be modified in bulk - so that the display is cleaner until the gap is developed.

 

Databases and Collection Facet

I am wondering why some databases are not displayed under the Collection facet.  Here is an example: search term "Courtship and Marriage".  I know there are tons of articles in JSTOR on this topic, yet, JSTOR is not displayed as a database under the Collection facet.  To be absolutely sure, I checked an article only available on JSTOR as shown below, but there is no JSTOR database listed under the Collection facet.  Am I missing something here?

 

Facets of CDI records will offer up to 20 facet values (those with the highest record counts).
This is documented here.

None of the JSTOR facet values made it to the top 20.
You'll see some JSTOR facet values with this search.

 

 

Disappearing Location and Author/Creator facets

The Location and Author/Creator facets may sometimes disappear, reappearing sometime later in subsequent searches.

The fix for this issue has been scheduled for Aug release.

 

Facet labels incorrect

Why is this facet displaying as lower case and singular, so it doesn't match the others?  This should come straight from Alma. We are not using local resources.  I can't seem to find any labels, code tables, etc. that don't have "Collection" properly capitalized.  To my knowledge, we haven't made any local changes that would affect this one facet.

 

It looks like we have a rule in our normal Primo that changes it to "Archival Materials" so I can't compare the records.

The records have LDR 06 = p and LDR 07 = c, showing more or less as expected as COLLECTION in PrimoVE and "Mixed material {Undefined}" in Alma.

There was an incorrect code (facets.facet.facet_rtype.collections) in Facet Resource Type Labels code table.

 

I can think of 3 possibilities regarding scenarios that all CSU sites are affected by;

  1. a faulty label (or missing code) in the OOTB code table - these will be addressed by Primo VE Development

  2. a faulty label carried over from BO during the Go VE automated activation - these should be corrected by the NZ administrator, or in each IZ.

  3. a label corrupted or removed by the Go VE automation - these will be addressed by Primo VE Development

The issue raised by Nikki matches #1. This defect was evaluated in the past, and it was decided not to be fixed in OOTB version. I've requested it to be reconsidered, and have created Case 00962419 for tracking.

SLO

Facets are missing numbers

Facets in VE do not show number of records available under each facet, as they do in Primo.

Primo VE does not include numbers for their facets as they are inaccurate. See

https://knowledge.exlibrisgroup.com/Primo/Knowledge_Articles/Configure_a_Custom_List_of_values_for_Library_Static_Facet/Counts_missing_from_availability_facet_in_Primo_VE

All

Facets question: Exclude full text online?

In Primo I have an option to exclude full text online in the facets, but in Primo VE there isn't an option to exclude (only include). See screenshots. Is this the case for everyone? Can I modify this?

It was decided in the past not to include this option in VE. As a matter of fact, it looks like it should have been removed from Classic Primo as well.
Anyhow, this feature doesn't appear to be working correctly in Classic Primo e.g. https://mlml-primo.hosted.exlibrisgroup.com/primo-explore/search?query=any,contains,harry%20potter&tab=everything&search_scope=EVERYTHING&vid=01CALS_MLM&facet=tlevel,exclude,online_resources$$I01CALS_MLM&lang=en_US&offset=0
The filtered search is returning results with available full text.

 

On our (current) Primo production environment, we have a Fine Payment link configured to send users to a static URL where they conduct fine payments.

Primo VE implements this through the Library Card Links mapping table, but also appends a &jwt=<JWT token> to the URL that we configure for the online_payment_url.

That's per instructions found at:

When the json web token (JWT) is added, our campus systems don't know what to do with it, and an error page is shown to the user, as seen below.

Bad Request - Invalid URL

HTTP Error 400. The request URL is invalid.

Is it possible to tell Primo VE to not append the token parameter?

This is hard-coded in the Primo VE Pay Fine Link, and cannot be left out.
This JWT contains the user_id and other relevant parameters.

What you can do is not use VE's Pay Fine Link, but rather display a link based on a static URL which will not carry over any user details. It would probably have to be done using JS if you wanted the link to display in the Fines & Fees tab.

Fresno

Force search slot drop-down

We used to be able to set showTabsAndScopes to true in order to force the display of the search scope dropdown menu on the Primo home page. Is that no longer available? 

It sounds pretty strange for that bit of JS not to work in VE, but I guess it's no longer an option if you've tested it.
The alternative is to use the following as your homepage: https://csu-csusm.primo.exlibrisgroup.com/discovery/search?tab=Everything&vid=01CALS_USM:01CALS_USM

 

Full text direct linking issues

Today, we discovered our links to full text from the brief record display, don't go directly to the full text instead they open the full record.   

I checked our configuration and it looks like we have direct linking configured:

 

Direct Linking doesn't work when the record's View It holds multiple services.

there is an issue where Direct Linking doesn't work for records coming from the NZ. VE development are aware of this and are working to resolve the issue. This will be fixed in November release.

 there is also an issue where Direct Linking doesn't work for some CDI records. This is being analyzed by VE development. I've created Case 00985506 for tracking. This will be fixed in the November release.

 

GES Appearing Twice on OpenURL originated records

I'm finding that some General Electronic Services configured to appear in the Links section are appearing twice in records originated through an OpenURL.

Example below:
https://csu-fresnostate.primo.exlibrisgroup.com/discovery/openurl?institution=01CALS_UFR&vid=01CALS_UFR:M&volume=5&date=2010&aulast=DeRosa&issue=2&issn=1748-3387&spage=91&id=doi:10.1038%2Fnnano.2010.2&auinit=MC&title=Nature%20nanotechnology.&atitle=Nanotechnology%20in%20fertilizers&sid=google

See the Report a Problem GES. I arrived at this record from Google Scholar.

The issue doesn't seem limited to Fresno only. I tested San Jose and Stanislaus on Primo VE, as seen below:

San Jose
https://csu-sjsu.primo.exlibrisgroup.com/discovery/openurl?institution=01CALS_SJO&vid=01CALS_SJO:01CALS_SJO&volume=9&date=2020&aulast=Lone&issue=1&issn=2222-1751&spage=1300&id=doi:10.1080%2F22221751.2020.1775132&auinit=SA&title=Emerging%20microbes%20%26%20infections.&atitle=COVID-19%20pandemic%E2%80%93an%20African%20perspective&sid=google

Stanislaus
https://csu-stan.primo.exlibrisgroup.com/discovery/openurl?institution=01CALS_UST&vid=01CALS_UST:01CALS_UST&volume=725&date=2020&aulast=Tosepu&issn=0048-9697&spage=138436&id=doi:10.1016%2Fj.scitotenv.2020.138436&auinit=R&title=The%20science%20of%20the%20total%20environment&atitle=Correlation%20between%20weather%20and%20Covid-19%20pandemic%20in%20Jakarta,%20Indonesia&sid=google

And it doesn't seem limited to VE. It happens for San Marcos on their current Primo Production instance.
https://csusm-primo.hosted.exlibrisgroup.com/primo-explore/openurl?sid=google&auinit=SA&aulast=Lone&atitle=COVID-19%20pandemic%E2%80%93an%20African%20perspective&id=doi:10.1080%2F22221751.2020.1775132&title=Emerging%20microbes%20%26%20infections.&volume=9&issue=1&date=2020&spage=1300&issn=2222-1751&vid=01CALS_USM&institution=01CALS_USM&url_ctx_val=&url_ctx_fmt=null&isSerivcesPage=true

The links are constructed at the following section, but I can't seem to find why some GES links appear twice but not others.
<div ng-repeat="link in $ctrl.getLinks()"

Has anyone else come across this and can you suggest a solution?

As this is an issue in Classic Primo as well, it's probably best to take it with Primo Support in a Salesforce case. submitted Salesforce case 00976724

 

Update: Development has set a target for resolving this issue no later than April 2022

 

Hold and Booking Request Form

trying to customize the Discovery->Getit Configuration->Hold and Booking Request form and I am unable to get some fields to display on the form. I enabled the Comments, Not Needed After, and Manual Description fields for public display. The Comments and Not Needed After fields show on the form, and I was able to change the label for the Comments to match our Primo label: Mailing Address:(Only for Delivery). However the Manual Description field is not displaying on the request form. What does this field display? Is there a way to add instruction text to the request form in Primo VE?
I followed the documentation found here: {+}

When requesting items that aren't cataloged, either a free-text manual description field or structured description fields can be filled-in.
I imagine that instruction text can be added using the customization package.
Update: Development planned for Q3 2021 for all types of forms (including resource sharing)
See: {+}

Update: Fix planned in July update.

 

UPDATE: Fix confirmed by CSUN to work.

Sacramento, Northridge and anyone that uses extra text on the request forms

How to "overwrite" NZ resource type with IZ general res type

Sonoma (and others) would like to use a more general resource type (videos) for their video resources. Currently, DVDs, videocassettes, and streaming video are separated by NZ rules.

I created a dirt-simple resource type rule in Sonoma's instance for videos, but it doesn't seem to be replacing the more specific resource types in searches. I did run the recalc local resource types, but nothing seemed to change. Is there something I need to do to get this to work?

 

Ex record: https://csu-sonoma.primo.exlibrisgroup.com/permalink/01CALS_SOL/18840tp/alma991002292629702921

the videocassette r.type in the NZ is overriding the video r.type in SOL when it comes to this specific record.

The definition of the local resource type depends on the owner of the record.
If the record is owned by IZ - the definition will be taken from the IZ.
If the record is owned by NZ - the definition will be taken from the NZ.
If the record is linked to NZ - the definition will be taken from the NZ.

991002292629702921 in SOL is linked to 991043211179702901 in the NZ.

I realize that is inconvenient if some of the sites but not all want the general r.type. I imagine that the majority of the data is owned or linked to the NZ.
Ben will take this up with VE Product Management.

 

ILLiad GES and Display Logic

GES is set so that it is never disabled, but the display logic is set so that if a full text service exists, the GES should be hidden.
This works as we expect it to in Primo, but does not seem to work in Primo VE. In Primo VE it appears all the time, even when we have full text for the article.
For example, if you look at the record for the article "A Meta-Analysis of Different Forms of Shared Leadership–Team Performance Relations" in Primo VE, you can see the full-text availability for Sage, as well as our print holdings (even though we don't have the issue that this article is in). Above the print holdings there is an ILL link. If you look at the same article in Primo, our print holdings don't appear (which is good, because we don't have this issue in print), and no ILL links appear.
We want this to work the same way it does in Primo. We don't have this issue, so the print holdings for the journal title shouldn't appear, and since we have it in full text, we don't want the ILL link to appear.
I'm just not clear why this works in Primo but not Primo VE.

There is a known issue where a Display Logic rule doesn't hide the GES in Primo VE. I've added your example to our internal report, and have logged Support ticket 00943256 for tracking.

 

Update: This is planned to be resolved during Q4 2021, with a possibility of a fix as early as August.

Sonoma, San Jose, SLO, San Bernardino

Incorrect Resource type displays

This ebook in Primo VE displays as a CD ROM resource type.  The record is coming from Alma CZ.  In Primo, it displays correctly.  My guess is that the record in the CZ from the JSTOR collection is incorrect, and that's the issue.  It displays as Book in other CSU who don't have the JSTOR collection.  Am I correct?
Red Blue and Purple America in VE
Red Blue and Purple America in Primo

This streaming audio example displays correctly as Audio in Primo but in VE, the resource type is CD/DVD rom.  I confirmed this is also happening in Sacramento VE since they also have Naxos Music Library records coming from  the CZ.  Is there something we can do about this?

Piano Recital: Cliburn, Van - BEETHOVEN, L. van / LISZT, F. / TCHAIKOVSKY, P.I. / BRAHMS, J. (Van Cliburn in Moscow) in VE

Piano Recital: Cliburn, Van - BEETHOVEN, L. van / LISZT, F. / TCHAIKOVSKY, P.I. / BRAHMS, J. (Van Cliburn in Moscow)  in Primo

This search on Democracy in America filtered by CD ROM resource type shows 9 results all of which are ebooks or streaming audio and should be labeled Book or Audio for resource type. I confirmed this is also the case for Sacramento VE.  The records are coming from collections in the CZ.

This record for Ordinary People in Extraordinary Times is an ebook in the JSTOR EBA collection from the CZ but it is labeled as AUDIO resource type in Primo VE.

This is concerning especially as I wonder how many more mislabeled resource types will be discovered.  Is there something we can do about this?

Recalculation of resource types may not occur properly. scheduled to be fixed during Q3 2021.

 

Invoke automatic search when search slots/scopes are switched

In Primo Back Office for Primo, there is a setting "Invoke automatic search when tabs are switched. Whether auto-search is enabled when users switch between tabs on a view.

This field is checked/enabled by default."  Documentation for that is here.  This is a nice user experience feature since the search is automatically repeated without manually selecting "search"  when switching between scopes.

We had to manually select search again when we changed the search slot in Primo VE. Is it our understanding that this is not available in Primo VE?   Will  this functionality be available at a later date?

We haven't received similar requests for this functionality in VE in the past.
There is a tentative plan to enable this in VE in the future.
In the meanwhile, automatic search when switching between tabs can be achieved using JavaScript. San Bernardino have add a section of code to their custom.js file in their customization package.

 

Issues with Everything search and complex phrase queries

A couple of campuses have noticed extreme slowness in returning results from queries consisting of 4 or more words using the standard "DN and CDI" search profile. One campus observed that this search contains e-inventory from all campuses, which is not desirable and also could be contributing to the performance issue. They created a search profile containing "physical items from NZ + e-resources available to me + CDI" and searches using this profile are much quicker.

  1. Is the DN & CDI search profile supposed to contain e-inventory not available to the campus by design?

  2. Is the complex query problem a known issue?

There are multiple issues here. One concerns Esploro records being returned in search results even when Esploro is disabled. This will be fixed in April release. The issue of 4 or more word search phrases causing slowness is being looked into as of Mar 9.
The inventory issue is "by design". The workaround is to create custom search scopes:SLO's scope for physical items at all CSU institutions (CSU+ scope): {+}https://storage.3.basecamp.com/3765443/blobs/82a60d64-86a1-11eb-b285-a0369f6bed60/download/image.png+
SLO's scope for owned e-resources: {+}https://storage.3.basecamp.com/3765443/blobs/be1a4694-86a1-11eb-b5f8-c81f66d3f0a2/download/image.png+
SLO example search profile to blend these scopes:{+}https://storage.3.basecamp.com/3765443/blobs/416598aa-86a2-11eb-a7fb-a0369f6bea8a/download/image.png+
{+}https://preview.3.basecamp.com/3765443/blobs/2397c942-86a2-11eb-bddb-22f4a2db5490/previews/full/image.png?dppx=1+

 

Update: Esploro fix in April release. Complex query issue assumed due to March indexing job.

All campuses are affected

Issues with Mobile Devices

Here are a few issues identified with mobile devices: 

  • The top main menu doesn't appear on either Android and iOS phones. 

  • On the full record display page, the Toolbar (citation, permalink, etc.) appears overlay, so we don't see the article or book title.  

  • The upper right corner Sign in and Menu don't appear on either phone.   The only Sign-in we could see is the Sign in to get complete results and to request items. 

  • No Sign Out option we can see once signed in. 

  • After selecting the "Stay signed in" option, we still have to sign in every time we come back. 

  • On Android phones, it appears the search results cannot be saved.  The saving records function works fine with iOS phones.   

Some of the content on the right of the screen shows up in landscape mode on iOS phones. The sign in link, for example.

In landscape, a part of the screen at the right is still cut off.

Using an Android phone (Samsung Galaxy 9), was able to mark and save search results. The top menu doesn't appear, but that's not unique to PrimoVE; it doesn't appear in PrimoBO either. Same with that top menu (permalinks, email, etc.) on the full record. It may be an issue with the Central Package customizations we made, which are many. 

 

 

Hiding the Purchase Request using Display Logic causes the link to the Purchase Request form in the links menu to give an error message saying "This form cannot be displayed." We want to enable the form from the Links menu, but not have the Suggest a Purchase link appear next to other requesting options in item/title records.

This is by-design in Alma. I see that Alma Product Management recently evaluated this area and concluded that changing the mechanism would require an enhancement request.
Have you tried hiding the Purchase Request link using CSS?

Sonoma

LC Classification Facet

We noticed that while we have a subjects facet, there doesn't appear to be an option to add the LC Classification for subject headings as a facet. We found this idea exchange about adding it and a comment about it: Adding LC Classification facet is planned for Q4 2019 as part of the feature alignment plans.
Is there an update for when this will be added as a facet?

Update: The current plan for this is Q1 2022.

SJSU, Northridge

Library facet labels just numbers now

Something seems to have trashed the labels for our library facets.  We've made no changes to these locally as far as I know.  This just happened this afternoon--it was fine a few hours ago.  I checked a couple of different browsers, cleared my cache/cookies, etc.

 

This appears to have been a temporary glitch.
(The number looks like a Library ID.)

If it ever occurs again, please notify EXL as soon as possible and they’ll try to catch it and analyze the cause.

 

 

Limit to identifier fields shows in record display

Our librarian found out that the following record shows different identifier in full display details section in Primo and Primo VE.
Primo Record:
Harry Potter and the Sorcerer's Stone (1st American edition.). A.A. Levine Books.
there are tons of ISBNS in the Identifier field. And there's another field just for OCLC with an OCLC number.
Primo VE record
Harry Potter and the Sorcerer's Stone
there are no ISBNs, no OCLC number. Just a LC number.

Each Display field or local field can process up to 19 output rows. If this limit is exceeded, only the first output row is displayed. Salesforce case 00936909 created to track issue
Update: Issue reported fixed by ExL on March 22.

 

Even when there are no links to display, the Links box appears, which makes it look like something is wrong and the links are just not loading. The Links box should not be displayed if there are no links to display.

I'm experiencing this as well on out testing environments.
It appears this is an issue that was already identified and resolved a few years ago.
I've sent a report to VE Development, and have created SF case #00943029 for progress updates once this project comes to an end.
The fix will come in the July 2021 release.

Update: Fixed in July release.

Sonoma, Northridge

Local field data remains in the PNX local_field even after the local field is removed from Primo VE

when removing a local field used for searching, will the content be removed from the search->local_fields section of the PNX record?
We added a local field for Search Key ID, which uses data from the 957 to search for records with digital bookplates. Enabling the field for searching allowed us to find items with matching ids. For example:

https://csu-csus.primo.exlibrisgroup.com/discovery/search?query=any,contains,bookplate%20259302&tab=Everything&search_scope=MyInst_and_CI&vid=01CALS_USL:01CALS_USL&lang=en&offset=0

 

We noticed the search->local_fields contained the following values for any record in the results:
local_fields" : [ "995 CSU ongoing load collection 2020-12-06 Master record variable field(s) change: 776 CSU interim load UPDATED", "994 92 CAC", "957 bookplate 259302", "956

Gift of Kevin Winter" ],
As a test, we removed the local field for Search Key ID and tried to find the records. The same search did not produce results (as expected) but a closer look at the same records revealed they still contained the Search Key ID in them.

created Salesforce case 00937039 for tracking purposes.

Update: After a thorough examination, it has been decided that a solution for this will not be part of the current Primo VE work plan.

Sacramento

local scope for external data source

We have an external data source of DC records that represent all of our institutional repository holdings systemwide. I have configured the import profile to bring all of them in and have tested a view to search across the entire set of records with no issues.
It is likely that individual campuses will want to configure their local searches to search the subset of these records representing their campus holdings in the IR. The campus value comes in using a non-standard DC field (dc:campus). I thought that I could use a norm rule to copy this value to a local discovery field and then define a local scope using that field as a condition, but it does not appear as an option.
Is there another approach that you would recommend to handle this case? We are able to do this "split" easily in PBO.

This should be possible using a local field, but you currently cannot map a DC field to a local field without use of a MARC field. SalesForce case 00929849 has been created to track a fix.

CO

Locations unsuppressed from discovery still showing no_inventory

I noticed that we had a location suppressed in Alma that we didn't want suppressed (our Resource Sharing Lending location), so inventory that was currently loaned out to another CSU wasn't appearing in Primo VE. I unsuppressed that location, but after a few days, that inventory still isn't appearing in Primo. 

I'm not sure if there is something else I need to, or if there is another reason this inventory isn't appearing. An example title is Corpus: A Home Movie for Selena (https://csu-sonoma.primo.exlibrisgroup.com/permalink/01CALS_SOL/12mrlk1/alma991028554569702901). We own this on DVD but it's currently in the CSU+ Lending location and loaned at to Dominguez Hills. The inventory isn't showing up in Primo (though the requesting options still are). 

The MMS ID for this title in our IZ is 991005472299702921. 

If there is another reason this isn't showing up in Primo, or if some kind of re-indexing has to happen when a previously suppressed location is unsuppressed, please let me know.

I'm going to run this by Product Management. I've created Salesforce case 00989239 for tracking.

 

Migrated e-shelf labels

We experienced the same thing at Sonoma as they did at SLO, with some labeled items appearing under the Unlabeled Items filter. Unlike at SLO, other labels did migrate over. 

 

 

I've created Case 00992488 for tracking the reports by
01CALS_USM
01CALS_PSU
01CALS_SOL
The resolution may take longer than initially presumed.

 

Newly configured facets require an Ex Libris reindexing of all records

According to the Notes located on {+}https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/050Display_Configuration/040Configuring_Local_Display_and_Search_Fields_for_Primo_VE+, new display fields used for search/faceting that are configured using norm rules require that reindexing be done. Only Ex Libris can run this job.

Ex Libris has responded on multiple occasions that they would only like to reindex the records once prior to going live, due to the system load that the process creates. They have said that they would be willing to run reindexing on a small subset of records that could be used to test rules. This seems to be a "case-by-case" offer but worth pursuing to those who might want to create substantial local facet fields.

All

I was just testing our Newspaper search and noticed something odd.  I see the same behavior in Classic Primo, so I'd like know if this behavior is by design or if I should open a case.

When I start my search in Simple Search and then click the Newspapers Search link from facets or the bottom of the page, I get Newspaper results as expected:

 

When I start my search in Advanced Search and then click the Newspapers Search link from facets or the bottom of the page, I get a blank search box and no results:

 

Is it expected behavior to drop the user at a blank newspaper search screen with no way back?

Indeed, this is by design in Primo and VE. As Newspaper Search doesn't support advanced search queries, the query cannot be carried over to Newspaper search.

 

The search term is not retained when going from Advanced Search to NP search, and therefore cannot be restored by the system. The browser's Back button, however, does take you back to the Advanced Search.
Also this behaves the same as Classic Primo.

 

It may not be technically possible to perform this action, so an Idea Exchange may not help.

 

Primo VE gap - Public Access Model doesn't support HTML

Access model, displays HTML. We have self-created HTML Public Note for access Model display in the full record display. This displays fine in the current Primo (OneSearch), but Primo VE shows the HTML only.

SalesForce case 00937205 created - fix in Development

Update: We're currently looking at H2 2022 as the time-frame for having HTML in Access Models supported in VE.

CSULA

Saved results, migration

Just giving this its own string because relevant messages are scattered all over the place:

There was a problem with the migration of saved results from BO to VE.

Initially, saved results that were NZ ebooks didn't come over. I believe this has since been fixed.

Some tags also did not make the migration. I don't have specifics, but in my case, a tag that I had applied to a group that was primarily (exclusively?) ebooks was lost and hasn't been recovered. 

I've created Case 00992487 for tracking the reports by
01CALS_ULA
01CALS_USB
01CALS_USL 
The resolution may take longer than initially presumed.

 

Source Record 856 URLs auto-mapping to VE Additional Services

Several CSU colleagues have reported source record MARC 856 field URLs being automatically mapped to the Additional Services section in VE's full record display. Though the genuine access URL appears correctly in the Get It area, the proliferation of non-access URLs in Additional Services will certainly cause user confusion and generate plentiful unnecessary problem reports. A clear example may be viewed here:

https://csu-fullerton.primo.exlibrisgroup.com/permalink/01CALS_FUL/oe38cr/alma991013283172802908

Primo VE's full record display Links section offers links cataloged in 856 $u as long as 1st indicator =4.
A workaround would be to either change the 1st indicator, or move the content of subfield U to a local 9XX MARC field. Both can be achieved using Alma normalization rules.
Following this discussion, VE Product Management are reviewing the Idea I mentioned earlier, and evaluating the possibility of adding flexibility to the 856 links functionality.Having 8564U mapped to Links section without flexibility was an intentional design.
In Alma, the correct way to manage electronic resources is by using e-portfolios (whether coming from the Community Zone, or managed locally). Portfolios can be managed centrally, as opposed to bib by bib.
As such, MARC 856 fields in the bib records are assumed to be additional links and not "main delivery links".

Fullerton, Sonoma, SLO, Northridge

Suppress Dedup/FRBR Rules

We had a couple of custom dedupe rules in PBO that we'd like to recreate in Primo VE.  

Do those have to be re-created for each institution, or is there a way to distribute those from the Suppress Dedup/FRBR Rules in the NZ?

We don't have a way to distribute the suppression rules from NZ to IZ.

For records coming from the NZ, the Dedup/FRBR suppression rules must be defined in both the IZ and NZ. You can try defining the rules only in the NZ and testing, but I'm pretty sure it won't work.
For records coming from the IZ, the Dedup/FRBR suppression rules are to be defined in the relevant IZ.

 

There are no numbers on the Availability facet

I noticed in the Primo VE documentation and in our Primo VE that there are no numbers (of records) next to the Availability facet as there is for our Primo NUI.  I noticed other live Primo VE also do not show number of records.  Is this a forthcoming enhancement?

Indeed, the Availability facet in Primo VE doesn't display record count. The top level facets are used for filtering the results at a very high level based on inventory across both the local and central index. These facets do not display numbers, in order to make sure we do not show even the slightest inaccuracies related to calculating very large number of records taking into account local and central data and also taking into account both Dedup and FRBR functionalities which impact the numbers users see.
I don't see a change to this functionality on the Primo VE roadmap.

 

SJSU has noted the following:

The record for this History libguide has links coming from other resources (subscription collections managed in the NZ).  It seems some sort of deduping is happening? That is not expected behavior. 

The record for this Architecture libguide also includes "related titles" for a Safari ebook. The Resource Type facet is missing as well. This doesn't happen in Primo record

Here is another example for Anthropology libguide displaying titles from subscription collections managed in the NZ.

Here is another example for Humanities libguide displaying an additional link to a NZ managed ebook subscription.

This is indeed related to the issue that VE Development are already working on. We don't yet have a projected resolution time frame. I've created Salesforce case 00955122 for progress tracking.

A fix for this issue has been scheduled for Q4 2021.

SJSU

VE settings reverted back to OOTB

On Friday, I noticed that our Primo VE display had somehow reverted back to what I presume are OOTB settings. This happened last month (April 7th), too. I reported it then here. Somehow, after I reported it, later that day, the issue seemed to resolve itself.
That time, only some records were showing the OOTB settings and some were showing our customized settings. This time, all the records I've tested so far seem to be showing OOTB settings in VE.
I created a demo explaining a few of our customizations (that we had been seeing until Friday when it reverted back to OOTB) and showing our VE as of this morning.
I had set aside some time on Friday to work on VE norm rules. It's difficult to test our customizations when the settings seem to sporadically revert to OOTB settings.
Is this happening to any other campus?

This can happen when there's an invalid norm rule that did not display an error upon Saving, but could not be compiled. Upon removing or correcting the faulty rule will bring back all local_fields and modified Display fields. Most invalid rule statements will result in a compilation error highlighted in red, and not allow you to save the rule. There are situations where the system is unable to detect the issue, allowing the rule to be saved, but failing when run on the VE records themselves. VE Development are aware of this, but I'm not sure anything can be done about it.

Sacramento