Stacey van Groll
My feedback
162 results found
-
100 votes
An error occurred while saving the comment -
1 vote
An error occurred while saving the comment Stacey van Groll
commented
This seems like a defect to account comprehensively for possible input into a search box.
-
42 votes
An error occurred while saving the comment Stacey van Groll
commented
I also agree completely with Elizabeth's comment for this functionality to be available by a job embedded within Alma and completely supported within that product, rather than a Cloud App.
-
109 votesStacey van Groll
supported this idea
·
-
4 votesStacey van Groll
shared this idea
·
-
71 votes
An error occurred while saving the comment Stacey van Groll
commented
Can it be advised what "GTI" stands for?
-
165 votes
Dear all,
Thank you for sharing this idea.
I have read it carefully, and would like to make sure that I understand it:
Current situation:
There are several processes in PO line workflow which add automatic internal notes, for example:
- Renewal ("PO Line has been renewed automatically on…")
- Moving PO line out of PO (""Line was removed from Order ...")
- other.
Desired outcome:
Have a configurable option to disable these notes from being created. Each of these processes is/will be saved in the PO line history.
Please let me know if this understanding is correct.
Thanks,
Zohar Shemesh
Alma product team
Stacey van Groll
supported this idea
·
-
0 votes
An error occurred while saving the comment Stacey van Groll
commented
I'm a bit confused between the features in play. Could an example be provided?
-
1 vote
Thank you for your suggestion. The Rialto team is reviewing this idea to determine how it might fit into our future plans. We cannot provide a timeline for these ideas, but be sure to check back often and vote for the ideas you support to receive status and comment updates.
Best,
Heidi Whitehead
Rialto Product Manager
Stacey van Groll
shared this idea
·
-
33 votesStacey van Groll
shared this idea
·
-
86 votes
An error occurred while saving the comment Stacey van Groll
commented
I have concerns that this suggested change would do more harm than good, given the known and observed situation of many CDI records only containing the physical identifiers. I believe a better option is to push Ex Libris to improve their metadata, which would require cooperation with providers providing this data for the index also.
-
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I'm sorry that I don't understand what this means.
Are you suggesting that only 1 request can be submitted and then all other patrons will try to place a request and get a message of being denied?
Or that they wouldn't see the option to place a request at all in the discovery environment?
Why are requests being cancelled for lack of copies? Do you mean your staff cancel them manually, as otherwise they would just be pending not yet active until a copy is returned?
I'm not sure how that would be less confusing to a patron to have to know that if the availability information is Requests: 1 that this means they can't place a request themselves.
Could it be explained a bit more? -
32 votes
An error occurred while saving the comment Stacey van Groll
commented
I have too few votes available to devote to this and we don’t actually use course information at our site, but am commenting support for the underlying premise of expectation of customer autonomy over what local data is searchable in their own discovery environment for their own records.
This is a logical and reasonable baseline standard, is available to customers using Primo managed by Back Office, and Ex Libris should have prioritised maintaining the option of choice when developing Primo VE, rather than deciding just to hardcode their chosen OTB. -
20 votesStacey van Groll
supported this idea
·
-
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I wonder if the existing Originating System field will meet this need? OTB this will display as Unknown but can be configured to display meaningful information, including by Import Profile. https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/080Analytics/Alma_Analytics_Subject_Areas/Titles
-
3 votes
An error occurred while saving the comment Stacey van Groll
commented
My prior comment was misguided due to Ex Libris having codes for this display in Primo VE as added from Primo BO (and displayed there in BO as configured), but despite this they do not show them in Primo VE. I was also misinformed originally in my case on this topic, being advised that the labels would only appear after transition to VE, rather than only during enablement.
They advise this is by design per usability studies on the link resolver that not all the labels are understandable with users tested expressing confusion of the meaning of different link resolver statuses. Therefore they decided to remove them for Primo VE display.
However, this completely ignores the possibility for a library to normalise these terms ourselves, as should be our right to decide, and in Primo BO we have made them the same for consistency and clear signposting to a patron as to the nature of the link action.
Instead it's just decided for everyone to take it away completely in VE (and yet leave the codes behind in configuration).
Given this supposed better design, I've also queried why there is still a prepend for Link in Record when presumably the same premise of confusion would reside there. In sum, the supposedly better design isn't even consistently applied. Hopefully this doesn't result in them just doubling down and extending this poor decision to taking that away as well.
Very disappointing and concerning decision-making from Ex Libris.An error occurred while saving the comment Stacey van Groll
commented
There is Code of fulldisplay.Access_content_in with Description option such as:
View online: {{provider}}This would seem to lead to the desired outcome if changing the Description accordingly in your environment per the example screenshot:
Click here for access: ProQuest Central -
1 vote
An error occurred while saving the comment Stacey van Groll
commented
Reasoning for logged in only included concern for ability for the user to add any email address for the export file to be sent and no sender information sent to know their identify, per the existing email functionality. With files upwards of 16 MB and more, this could be used quite maliciously without any verification of the sender at all, including clogging up CRM systems with massive files in quick succession and inability to prevent this other than strategies like blocking the Primo From address or setting rules to send to spam or disabling the feature completely.
There are also system performance impacts to consider with bulk sendings. -
52 votesStacey van Groll
supported this idea
·
-
15 votes
Thank you for your suggestion. The Rialto team is reviewing this idea to determine how it might fit into our future plans. We cannot provide a timeline for these ideas, but be sure to check back often and vote for the ideas you support to receive status and comment updates.
Best,
Heidi Whitehead
Rialto Product Manager
Stacey van Groll
shared this idea
·
-
112 votesStacey van Groll
supported this idea
·
Could some user stories be shared as to how particular information is used by staff in practical situations? We use statistical categories too for things like reporting engagement by loans of physical collections, but I'm not thinking of any scenarios for ours where they would need to be immediately visible for circ desk interactions like loaning a book.