2 votesStacey van Groll shared this idea ·
Hi Dan - could you advise exactly what the job report says now for the scenario of autorenewal not occurring due to expiry date being within the renewal period, and what you'd like it to say instead? I'm not clear on that after reading the case.
I might be missing something, but if wanted at an admin level of control, there is already an easy way of setting the schedule configuration from Active to Inactive.
Hi Gran - Thanks very much for clarifying the intent of the idea. I agree that the Blocks display in Blocks + Messages are very limited at the moment, and it would be good to have them all displayed there for user information. This would also help in making up for the 2 block limit for nonrenewal reasons in the Loans tab. I will add a vote in support.
User specific blocks and loan specific blocks are both displayed, but the key is the design decision to only display 2 blocks maximum.
The user specific blocks display first and then the loan specific, in a certain order. I had a case querying this and asked for the details were added to the OLH:
1. The following patron blocks are checked first to see if all loans are blocked for renewal. Alma will return the first two reasons found and will not perform any further checks.
a. Patron is expired.
b. Check if patron overdue recall limits were exceeded.
c. Fetch patron's active blocks.
d. Check if patron overdue limits were exceeded.
e. Check if a patron's cash limits were exceeded.
2. The following loan-specific checks are performed next. Alma will return the first two reasons found for that loan.
a. Validate that the item is renewable.
b. Check if the user has a patron role for this library or the whole institution.
c. Validate that the current date is before the maximum renewal period expires.
d. Check that the item does have any holds.
We changed the first code table display from 'Cannot renew this item' to 'Cannot renew this item. Reasons include:' to try to establish the user expectation that there may be more than the 2 displayed reasons.
Thank you for your feedback.
Today Primo does present viewit services for resources that do not have full text indications.
We will check with Primo if this can be changed as the Unpaywall service can appear also when there is no full text service.
Note that this issue is not relevant to PrimoVE
I think you’re being too hard on yourself with this, Deborah, as when I look at the text of your original idea, it clearly states in the first paragraph: “… this could fill about 50% of recent articles that show in Primo for us as "no full-text available".”.
It is very obvious the use case you were making that the Unpaywall link is needed in ‘No fulltext’ scenarios, for example nui.getit.alma_tab1_nofull.
You suggested a potential development pathway, but it is for Ex Libris to implement in a manner which fulfills the submission, if they decide to mark as Under Review, then Planned, and then Completed.
As it currently stands, I think that the original idea should not be marked as Completed if it only appears in no fulltext scenarios for Primo VE, but not for Primo
Dana – could you please advise how and why this is not also an issue for Primo VE? Does it perhaps appear in the ‘How to get it’, as these appear to be locked behind auth in the VE sites I checked?
Thank you for posting this suggestion, we are considering the option to add a Request Type Filter to help users filtering requests by type (ILL, Purchase, Digitzation, Request ,… )
For visibility in Primo, there are a couple of benefits that make it appreciated:
1. Some staff are more comfortable with the Primo UI, rather than certain aspects of Alma like Manage Purchase Requests facets, and they are already actively using Primo for many activities when they may also like to check on a past purchase request. The speed of being able to do so from within the UI they're already typically actively using, especially as some will have no need to log into Alma on many days, is also a plus
2. There is the Primo feature from Requests of being able to click on the title and go directly to the full record, which is a quick workflow to find the record in discovery, grab a permalink, etc. Although I have set up Analytics reports for purchases which include the URL to the Primo record both from within Analytics and after export, this does again require them to navigate to the report. If they, for example, get a query from a user about a purchase request submitted on their behalf, they can quickly go to Primo, Requests, find the title, click on the entry, and go from there.
These aspects will inevitably be particular to workflows of different sites. As an example, we mediate all purchase requests through liaison librarians rather than offering the option for users to submit requests directly, And we also choose to publish all orders straight away to Primo, rather than waiting for receipt, so that users can see that requests have been actioned and anticipate addition to the collection.
As such, the visibility for these librarians of all the resources they've requested directly in Primo is a positive experience.
I can understand that sites without these sort of workflows might wish to remove these entries for non library staff users, but it's important that changes to UI take all usage variations into consideration, hence my alternate suggestion.
Our librarians quite like that their purchase requests are visible in Primo.
Perhaps, instead of removing them, a dropdown option could be introduced to Requests for all Requests History, as there currently exists in Loans for Historic Loans.
This would also fulfill this request: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/38591101-my-account-previous-historic-requests
I actually thought this was likely to be a deliberate design feature (although I've never asked). The half panel display on either side suggests to me that there are more resources available, rather than just the ones on screen, reinforcing the user expectation established with the bars on either side with the arrows. Up to 100 records will be displayed, combined to the left and right, with the open record in the middle, so it's correct that the list is not complete.
Could you share the use case of why this would be useful? For staff this information is available in the equivalent form within Alma, and I can't think why a user would care how many times an item was loaned.
I agree that you should have the ability to configure this, just as Primo Back Office does.
Did Ex Libris ask you to submit this entry though, as it seems to me there might be a bug here?
The search initiates on Potter, Harry, 1954- even though the $$Q is without the date:
<creator>Potter, Harry, 1954- author.$$QPotter, Harry</creator>
And then the search fails to match with the facet term, even though the search data appears to be the same as the facet in UI, but is different in the underlying data:
<search><creator>Potter, Harry, 1954- author.</creator>
There are many potential root causes of this, but it depends on a number of factors.
Is this on Primo BO or Primo VE?
Are you using the out of the box EasyBib styles or the GitHub styles?
Is it an issue via records directly in Primo from PCI, or via the services page into Primo from an external source?
I have voted for this idea as I would like to be able to interrogate our live data about our users directly in our LMS as needed. For example, as an admin, I typically need to do testing for various system configurations and issues, and have had the need to find some current users by key elements. I have been prevented from doing this quickly and easily by Alma limitations of user search, and have been forced into the significantly more laborious process of loading Analytics, which often has caching delays and also disrupts other reports I might be running on historical data. This then needs even more back and forth checks between Alma and Analytics to find accounts which have not changed in the preceding day after ETL, as this data is not current. It does not seem unreasonable that library staff should be able to use our LMS to find our own data in ways that are practical to our daily work, and this is just one example.
Hi James - Did Ex Libris classify this as an enhancement rather than a defect, and direct you here? This is not right if yes, as if a subject heading lateral link with a hyphen requires quotation marks in order to function as expected to return results, then it should be included in the query by the system at the point of initiating the action.
I see that your search also functions as expected when removing the hyphen and leaving a space.
I have checked this on our Primo Back Office site, set also to exact phrase action, and it is working as expected with both the initial lateral link and also when initiating the search again after removing the hypen and leaving a space, which is expected with the Search Engine Configuration option also of Remove Hyphens as the default.
It seems clear that this is a defect with Primo VE that should be fixed.
Hi, If the documentation indicates that running a job is possible for a role, but it isn't available in your Alma environment, then this is a bug which should be reported to SalesForce. It is also possible to remove the other jobs from the role by requesting this in SalesForce. For example, 'Change Physical Items job' is by TASK_CHAIN_ITEM_INFORMATION_UPDATE and so all TASK_CHAINS bar this one could be removed.
Have you checked the Events subject area of Analytics? I haven't done a full assessment, but I think your minimums are pretty much covered there, as security events.
I believe that the earlier idea referenced is incorrectly marked as Complete.
I have added a similar comment to this on that idea, noting that the content of the request was clearly for AND, and yet the development in-system is OR, in that only one field can be used.
In this way, it is also not correct that this functionality is marked as Complete on the Primo VE Feature Alignment page when it is also there as AND: "Local Resource Type Normalization for MARC Leader and Fixed Fields".
It is not right that a clear request can be submitted, be accepted and Planned with no indication it would be limited, and then the community waits for release six months, only to find that it is not what was asked for or what was promised.
Then the whole cycle starts over again with the idea here.