Alma
Your feedback matters to us. Help us improve Alma by telling us what you’d like to see using the message areas below. You can also can support something already posted.
We would love to be able to respond to every idea that is submitted, but this is not feasible. We are, however, committed to responding to the most popular ideas—those that have received the most points.
For more information please review our FAQ and guidelines. Thank you.
23 results found
-
Add option to specify electronic collection in Create PO-Line API
When an electronic portfolio is created by GOBI through the Create PO-Line API, it is automatically set to standalone. The Create PO-Line API has no option to specify that it should be part of a specific electronic collection.
In our use case we thought we could fix this by using the update inventory import profile when importing a more complete MARC record, but if this profile is configured with a collection a new portfolio will be created if the existing is standalone. (See case #00500768.)
Allowing an electronic collection to be specified when creating portfolios through Create PO-Line API would…
1 voteAs part of July releasefor orders originating from GOBI, Alma will attempt to locate the relevant portfolio located within a Community Zone collection using the vendor proprietary identifier number or the ISBN/ISSN and activate it within the relevant collection in the institution.
For more information please see
https://knowledge.exlibrisgroup.com/Alma/Release_Notes/2020/Alma_2020_Release_Notes -
Populate library hours from other sources
Currently Alma does not accept a feed of library opening hours from other sources, we would like ExLibris to add this feature for better integration with other calendars. Currently Alma API can retrieve and output library open hours, it would be nice to have an API that can read and update library open hours.
1 vote -
Use sane file permissions on gzipped files from publishing jobs
When extracting the MarcXML-files from a publishing job, the extracted files by default have unix file permissions set to 060 (u=,g=rw,o=), i.e. only readable and writable by the group, not by the user. This is weird and makes little sense.
Even worse, it also means that on systems with default umask of 022, which is very common, the effective permissions will be 040 (u=,g=r,o=) which means that the files can be neither changed nor deleted – even by the user who extracted them – without messing with permissions.
I can see no reason whatsoever for preferring the current default set…
0 votes
- Don't see your idea?