Primo VE – Hidden configuration options

PrimoVE_add_secondary_sort

• Description: Adds a secondary sort to address issues when duplicates are returned due to the same score assigned to a large group of records, with ‘large’ being relative to the query
• Default: False
• Visible to Discovery Administrators: No
• Available as of: November 2024
• Documentation: Not documented, including not in the November 2024 Primo VE Release Notes
• Additional details:
  • The setting was advised to exist in December 2024 in case 07811535 Primo VE – Same records appearing on multiple pages of the same list of results, with issue of searching for database* with 800+ results and seeing the same records appearing repeatedly on multiple pages of results
  • The issue is also suspected to cause a related problem of other records being missing from the results set, as replaced by instances of record duplicates
  • The setting is suspected to have contributed to resolution of an issue in another case, due to the timing of Ex Libris Support changing the parameter to true: 07809568 Primo VE – Support Bulk Export of All Search Results – Failure to include all records for bulk export emails, with inconsistent file contents at each attempt

———-

primo_ve_enable_browse_search_paging

• Description: Introduced to fix performance issues with Browse Search failing to return results at all, or taking a long time to do so, when over 1000 via Alma > Browse Bibliographic Headings
• Default: True
• Visible to Discovery Administrators: No
• Available as of: August 2023
• Documentation: Not documented specifically by parameter name nor in the main OLH (Configuring Browse Search for Primo VE). Included in the August 2023 Primo VE Release Notes only by feature header of “Improve Performance of Browse Search”
• Additional details:
  • When the setting is true, it is expected to also disable FRBR and DEDUP in Browse Search and removes the total number of search results
  • However, there is also a side-effect to cause also: 07187920 Primo VE – Incorrect results display when navigating from Browse Search to main Primo by lateral link, with outcome that the results display is only “1-10” instead of 1-10 of xxx results also in main Primo when navigating in by lateral link from Browse Search. It was advised by Ex Libris that this defect will not be fixed
  • Also, when true and pagination is set to 25 or 50 there is inconsistent display of an error message: “Some records are not displayed since they are restricted / suppressed from display” (07235456 and 07186535). It was advised by Ex Libris Support that this defect will not be fixed

———-

“unnormalize” Creator/Contributor facet

• Description: In order for the Creator/Contributor facet to include CDI results in blended search, the facet values should be formatted as “Last name, First name” in Primo VE. This requires changing an internal configuration to unnormalize the facet
• Default: False
• Visible to Discovery Administrators: No
• Available as of: Unknown
• Documentation: Not documented
• Additional details:
  • Existence of this setting was advised in March 2025 07953676: Primo VE – Creator/Contributor facet fails to add CDI records to facet count and facet values for selection
  • If the setting is true, then facet counts do not include CDI records
  • If the setting is false, then facet counts include CDI records, but there is an issue of unexpected facet values with incorrect facet counts, correlated to diacritics. This issue is already known and with Development as an open defect
  • The default setting is false as advised for customers who do not want this facet to be unnormalized and anticipated performance issues if done for all customers due to the amount of indexed data
  • Ex Libris will not document that the setting exists, with statement that it is an internal configuration not accessible to customers
  • Changing the setting does not show any visible change in the record PNX to reflect the data being “unnormalized” or not

———-

“discovery facet indexing without normalization”

• Description: The setting corrects an issue with lower case in local facets from external source records, with original source capitalisation restored when the setting is true
• Default: False
• Visible to Discovery Administrators: No
• Available as of: November 2023
• Documentation:
  • Not documented in main OLH, and only included in Resolved Issue of Release Notes for Primo VE November 2023 without indication that a case is required for setting change options: “November 2023 SF: 6227389, 6602566, 6651892, 6791531, 6796374, 6881582 For external data sources, facets were displayed in lowercase. This has been fixed.”
  • Ex Libris Support confirmed correlation also to the Primo VE March 2024 Release Notes Resolved Issue, but this was not mentioned in the original case: “March 2024 SF: 6623808, 7008342, 7009590, 7035352: For blended searches, the Subject facet has incorrect counts and duplicate facet values. This has been fixed, but you must contact Support to enable discovery facet indexing without normalization.”
• Additional details:
  • Existence of the setting was advised July 2024 in case: 07242461 Primo VE – Local Facet values not capitalised for external source records
  • Ex Libris Support has refused to document or name the code exactly: “Following the fix, a new internal parameter was introduced. When set to false this parameter is affecting the normalization of local fields.”, “The internal parameters are designed for technical staff only. We have recorded the parameter change in the case internally. You can always mention this case in your future references. For your internal purposes you might want to record the configuration as ‘discovery facet indexing without normalization’.”, “The internal parameters are set by the Product Manager decision. So there is no customer documentation for them. I assume the same applies to the OTB behavior. When the majority of customers are satisfied with a certain OTB value, we do not change it just because it is problematic for another customer. In such cases, we offer to enable the parameter for the affected customer.”
  • Ex Libris Support correlated the same setting as “similar” to issue reported March 2025, in referencing the same internal configuration: 07953676 Primo VE – Creator/Contributor facet fails to add CDI records to facet count and facet values for selection
  • Given the number of cases for different fields, it is currently unknown but suspected that the setting can be applied or not to different fields

———-

discovery_customer_defined_exact_match_field

• Description: Introduced to fix relevance ranking issues by boosting a specific field
• Default: None unless configured by Support
• Visible to Discovery Administrators: No
• Available as of: Unknown
• Documentation: After IGeLU Primo WG advocacy, the following was added to the OLH for Configuring the Ranking of Search Results in Primo VE: “Note: For some exact title searches, the matching record may not appear in the first few results because other boosting factors (such as for records that also include MARC 245 $b) may give other records a higher boost. If this is an issue, contact Support to configure the discovery_customer_defined_exact_match_field system parameter, which enables you to give a higher boost to a specific field and subfield (such as MARC 245 $a). Note that this type of boost is limited to one field and subfield, and if the specified field is repeating, only the first occurrence of the field is used for boosting. In addition, this option requires re-indexing to apply the change.”
• Additional details: Additional aspects not documented:
  • There is no use of MARC filing indicators, only the single defined field and subfield
  • The parameter will apply to the search query without a stopword, or including one, making it irrelevant if initial articles are catalogued
  • The parameter applies to the standard Primo VE search only, and not Journal Search
  • There are further aspects for consortia, requiring for the internal parameter to be configured the same in both IZ and NZ and therefore it is not suitable to use a local extension field in Network environments
  • The setting requires all other ranking configuration to be set to the default values

———-

enable_guest_user_for_dlr

• Description: Introduced to fix an issue with links hidden for users not logged in (aka Guest) with use of Display Logic Rules by user groups
• Default: False
• Visible to Discovery Administrators: Yes
• Available as of: October 2021
• Documentation:
  • Primo VE October 2021 Release Notes: “Display logic rule to hide electronic collection for specific user group also affects Guest users. This fix requires you to set the new Discovery customer parameter enable_guest_user_for_dlr to true.”
  • OLH description: “When set to true, display logic rules are applicable to guest users when service restrictions pertain to user groups”
  • UI parameter description: “Enable ‘GUEST’ user to be considered for Display Logic Rules. Please note this configuration requires the ‘GUEST’ user group to be configured in Alma”
• Additional details: From cases 07226072 and 07245514
  • By default, when a user is not signed in, Alma is unable to determine whether the user is part of any restricted rule.
  • In other words, if a display logic rule prevents display for any user group, it will also hide it from guest users.
  • Setting enable_guest_user_for_dlr to true, at Configuration > Discovery > Other > Customer Settings will allow users to view GES links without logging in first. The only GES links that would be impacted are those that are set to Enable without login = Yes.
  • The parameter is not specific to any one Display Logic Rule and is an overall setting for your entire environment.
  • If you have display logic rules that uses the Guest group, (for ex. : For user groups Alumni,Guest: Hide service Resource Sharing Request with Resource Sharing System = Alma), before setting it to true, a DLR with “For user groups Alumni,Guest: Hide service Resource Sharing Request with Resource Sharing System = Alma” would have hidden it for Alumni and Guests.
  • Before setting the Customer Parameter to true, anytime there was a DLR hiding something for a particular user group, it would have been hidden for guests too.
  • Now that the customer parameter is true, the system will only apply the DLR to the user group specified (Guest, Alumni, Staff, etc).
  • The parameter enable_guest_user_for_dlr was developed in 2021 for Primo VE to allow ‘View Online’ and ‘full text’ links to continue to appear in Primo VE, similar to Primo Classic : if display logic rule exists to hide electronic collection for specific user groups, it will not affect guest users (as long as the display logic rule does not restrict the guest user group from seeing the service).
  • When introducing the enable_guest_user_for_dlr parameter, we were asked to address the scenario of displaying the links to electronic collections in the record prior to sign in.
  • For example, before this parameter, when you searched for something electronic, you could check the record but without the link unless you are signed in.
  • This was OK for offsite users, but not for on site users who would prefer the link surfacing without sign in (as some of them do not have a login or the current EzProxy set up does not require sign in when coming from an onsite IP).
  • So, the parameter as introduced, keeps restricting certain collections from logged in users but no longer affect Guest users: the service hidden for other groups remains visible for Guest users.