J. Collins (UBE, SLSP)
My feedback
21 results found
-
19 votes
An error occurred while saving the comment J. Collins (UBE, SLSP)
supported this idea
·
-
12 votesJ. Collins (UBE, SLSP)
supported this idea
·
An error occurred while saving the comment J. Collins (UBE, SLSP)
commented
We strongly support this idea.
Currently, managing institution-level bibliographic sets in Alma requires the Repository Manager role. However, this role includes a broad range of permissions that are not all necessary for managing sets, for example:
• Running jobs for bulk updates
• Performing metadata changes on NZ and IZ level
• Running import profilesFor everyday workflows—such as managing Primo collections based on bibliographic sets—which in many institutions, including ours, are not carried out by administrators, we are required to grant staff significantly broader permissions than are actually needed for these tasks. This goes against the principle of least privilege and unnecessarily increases the risk of unintended metadata changes.
In our view, Alma would benefit from a dedicated role that is limited to managing Alma sets and Primo collections, including the ability to:
• Create and edit logical and itemized sets
• Add or remove records from sets
• Manage set ownership and visibility (e.g. for Primo publishing)
• Edit institution-level sets regardless of the original creatorAt the same time, this role should explicitly not include permissions to run global jobs, perform bulk updates, execute import profiles, or make institution-wide metadata changes.
Such a solution would provide a much more secure and flexible permissions model.
-
40 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
46 votesJ. Collins (UBE, SLSP)
shared this idea
·
-
134 votesJ. Collins (UBE, SLSP)
supported this idea
·
An error occurred while saving the comment J. Collins (UBE, SLSP)
commented
Great idea! We could really use this to reduce duplicate purchases in acquisitions in our IZ. Our staff users have purchasing rights scoped to certain libraries. When they want to order a certain title, they do see, if there's an order attached to it already from a different library, however they cannot view it in order to tell, if it's was received or cancelled, or if it's even a subscription.
-
112 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
88 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
107 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
7 votesJ. Collins (UBE, SLSP)
supported this idea
·
An error occurred while saving the comment J. Collins (UBE, SLSP)
commented
I strongly support this idea. A start month or even a start date would be very helpful.
In November I was setting up a report, which is to be sent once every year at the beginning of February. I had to wait until the beginning of January in order to schedule it correctly. -
33 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
132 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
79 votesJ. Collins (UBE, SLSP)
shared this idea
·
-
75 votesJ. Collins (UBE, SLSP)
supported this idea
·
An error occurred while saving the comment J. Collins (UBE, SLSP)
commented
In addition to that, we'd also greatly appreciate the addition of the reporting codes in the po line claim letter (respectively in all acq letters in which they aren't available yet).
-
70 votes
An error occurred while saving the comment J. Collins (UBE, SLSP)
commented
Additionally, the Claiming Grace Period (days) from the PO line would be very helpful. This would enable better POL clean-up, for example in preparation for switching from manual to automatic claiming.
J. Collins (UBE, SLSP)
supported this idea
·
-
78 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
110 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
49 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
48 votesJ. Collins (UBE, SLSP)
shared this idea
·
-
42 votesJ. Collins (UBE, SLSP)
supported this idea
·
-
49 votesJ. Collins (UBE, SLSP)
supported this idea
·
We support this request; it would be very useful for us too.