It would be nice to be able to move up and down within a field using arrow keys in MDE. For example, when a lengthy 505 or 520 MARC field has many lines, the cataloger must now move to the desired line using either mouse or left/right arrow keys, since pressing up/down arrow causes the pointer to move to the previous/next field.

My suggestion is that the pointer should be able to move within the field using up/down arrows and move only to the previous/next field when the pointer is on the first/last line of the field.

Using up/down arrow keys when moving within a field would streamline cataloger’s work and help making the MDE more user-friendly.

This feature would add the ability to load and export split coverage date ranges for Alma portfolios. Currently, the portfolio loader only allows uploading continuous coverage date ranges. However, in some cases, a journal has split coverage dates. For example, we might have access to a journal from:

1980-1995
1997-present

Currently, there is no way to upload this using the portfolio loader; the portfolio loader will only load one of the date ranges. This means we must do extra manual work to enter these date ranges in the portfolio editor.

Also, the standard portfolio export features in Alma, in cases where a portfolio has split coverage dates, only export the first range. In the above example (coverage from 1980-1995 and then 1997- present), export options (such as "extended export") only export the first range (1980-1995). This creates confusion when performing exports, as the export sheet does not contain accurate date range information. The only way to export split coverage from Alma is to use Analytics.

These improved import and export capabilities should be added for all uploadable date fields and all exportable date fields, including both the current coverage dates that display in Primo and the perpetual access date fields only visible in Alma.

There is no easy solution in Alma FF to indicate that an item has been consulted in the library and that it can be reshelved.

When items are placed on the hold shelf and are briefly consulted in the library, there is no easy way to directly reshelve them in Alma FF. The workarounds are far from ideal and are very labour-intensive when facing a large amount of physical requests: cancel the request (but this is not correct and influences our request statistics) and reshelve via the expired hold shelf, update the expiry date to yesterday (but this requires a lot of clicks) or wait until the item automatically appears on the expired hold shelf and reshelve from there. With this last option there is too much time between the moment of consultation and the moment of reshelving, which makes that items are not available on shelf or for request for a too long time period. It also makes that new features like the hold shelf reminder letter cannot be set up (because patrons could receive a reminder when they already consulted the item).
Possible solutions are: for an item that is scanned in via ‘return items’ the underlying request will disappear and the item will be reshelved automatically. A button ‘consulted’ (like there is a button ‘cancel’) which immediately reshelves the book when you handle a request is another – less preferable – option.

I would like to suggest two ideas which can improve the whole management of working with physical item editor:
1. Enable all tabs and fields to be editable without clicking on 'save and edit' button – Currently after you click on 'Add item' and being navigated to the 'Physical Item Editor' form, not all the fields and tabs (General, ENUM/CHRON, Notes, and History) are enabled for editing, the barcode no. is not populated automatically, and the dropdown list of process type is disabled as well. Only after clicking on 'save and edit' button, the complete form, including the tabs are enabled for editing. Therefore, each time you need to add an item, you have to go through 2 phases: 1) fill limited number of fields and click on 'save and edit' 2) edit more fields, choose process type, and add public/internal notes (if needed) and click on 'save'. This workflow is extremely long and if all tabs and fields were enabled for editing in one flow, it would make the whole process faster, easier and prevent users from making mistakes, in cases where they forgot to fill some fields.
2. Add 'Save as Default' button – Cataloguers who most of the time handle the same material type or fill/choose the same content for several fields (including process type) and, etc. would be glad if there was an option to save the content of number of fields as a default, so they don't have to fill them for each item.
I'm aware there's already an idea to add templates to handle this, but I believe this will extend the workflow, because when the cataloguer wants to add an item, first he'll be directed to a screen where he has to choose to load from a template (same as it works with POL's templates) and only then he can fill out any missing data in the form, such as receiving date, enumerations, description, and etc. Hence, the 'Save as Default' button will solve this long workflow and save precious time, so if the user would like to save fields with content and update them from time to time (similar to how it worked in Aleph), he can do it easily and quickly.

Please support this idea.

Thanks,
Ruhama.

The configurable blocked actions for user blocks in Alma are:
01 – loan
02 – loan, renew
03 – loan, renew, hold

It is therefore possible to configure that blocked users are not allowed to place requests at all.

We propose a distinction between the different request types in blocked actions.

Blocked users should be able to place hold requests, as it can be checked at the latest at the time of loaning whether there is a block, and users then have to take care of the unblocking (e.g. by paying fees) in order to be able to loan the item.
Document delivery, on the other hand, would like to prevent blocked users from placing digitization requests, since there is no check for a block before the scans are delivered and therefore the service can be used permanently without staff and users being notified about the block.

We encounter a lack of important functionality to efficiently follow-up on In transit requests (physical item requests to another pick-up location). We would like the functionality to be extended with the following additional features:
1. A patron facing letter when the requested item is placed “in transit” by the owning library, so that the patron is better informed of the status of his request.
 We want to create a situation that once a requested item is being transported, there is in fact no way back and a fee needs to paid.
2. To make it impossible for patrons to cancel their request in Primo once the requested item is already in transit or on the hold shelf in the pick-up location.
 We need a granular setup config to define the end user cancellation option in Primo based upon the status of the request.
3. A letter to the owning library when a patron is cancelling his request in Primo, so that the owning library might avoid sending items that have already been cancelled.
 Context: multiple different libraries within 1 institution, and some of these libraries handle dozens of request per day based upon the request slip. This means:
o It’s too time consuming to check the expired hold shelf for all items which are possibly cancelled…
o A cc or bcc added to the cancellation letter is not an option, because this is an institutional letter and cancellation request letters will come in from multiple libraries… The ‘alert’ / letter needs to be owning library specific!

It would be great if we could use templates for adding new items.
At the moment, whenever we add an item, for each single one of them we have to manually fill in the same values in "Material type" and "Item call number type". The "inventory date" has to be chosen manually as well.
It would be extremely useful if we could load the physical item editor form with some values already filled in, and with the date fields automatically filled with the current day's date.

If this idea has already been posted or it the option already exists, please let me know.

Thank you and kind regards
Barbara

Currently a valid NCIP request from anywhere can retrieve information about a given library's patrons. In order to exploit this, the attacker would need to know server address, institution code, code of the profile for ILL, all of the correct metadata, and the correct message type/formatting. It's not trivial to gather up all that information for a given institution, but much of the information is publicly available (e.g. NCIP message formatting is a public standard), and none of it is generally treated as a secret.

Given the continuously evolving state of library systems security, it would be good to prevent this type of attack before it happens. Protecting patron privacy is meant to be a top concern for libraries, and we need to embody that principle.

Possible means of fixing this security concern could include requiring an API key be sent with NCIP requests, or allowing each library to configure trusted IP addresses from which to accept NCIP requests.

Presently, only changes made to some fields in an electronic collection record are tracked on the Electronic Collection Record History tab. For example, if I enter text in the Description field on the Electronic Collection Description tab, the History tab shows a "Modification Date" but does not indicate what field was modified. If I change the Access type field on the General tab, the History tab does not record that any change was made.

The usefulness of the History tab is greatly reduced if not all field changes are tracked. It is more difficult to trust the system or to use the History tab for training or auditing purposes (e.g., determining what operator made the change and why).

Automatic processes in Alma make library staff save time and efforts, but also significantly reduce human interactions with patrons (very few emails are personally sent by librarians to patrons). Lots of Alma letters sent to patrons are nameless and only signed by generic service names like "Acquisitions Department", "Circulation Desk", "Library ABC" etc. (see @@department@@ in the Labels). Some staff members suffer from this dehumanization in the processes.

We want to give a name and a face to a request when patrons get notified and would like to enrich some Alma letters with the name of the librarian who took care of the requests and add a line like for example "You have been served by: Jane Smith". Behind the librarian's name in the letter, the customer could create a link to the librarian's webpage, LibGuides profile pages, the University directory, etc. with the XSL template.

For at least the last staff member who worked on the requests (item hold at the circ desk, digital material sent, item received/activated...), please add the following staff User information:
- First name
- Middle name
- Last name
- Preferred middle name
- Preferred first name
- Preferred last name
- Primary identifier
- Job category
- Job description
- Website URL
in the XML of the following Alma letters:
- Document Delivery Notification Letter
- Ful Cancel Request Letter
- Ful Digitization Notification Item Letter
- Ful Personal Delivery Letter
- Interested In Letter
- On Hold Shelf Letter
- Purchase Request Status Letter

Currently, the publisher location is not indexed in the general "Keywords" index in Alma. If someone wants to search for a certain publisher location, one must use the specific index because a "Keywords" search won't bring any results.
This is particularly unpractical when searching for series or periodicals, as they often have similar names but different publishers or publisher locations, or later editions of a certain work which can be identified by the different publisher resp. publisher location.
What confuses staff users is also that if one wants to search for a book, using the title and/or the author as search terms leads to useful results but the simple addition of the publisher location brings no results at all.
For these reasons, we suggest adding subfields 260 $a, 264 $a, 533 $b, 752 $a-g to the general "Keywords" indexing.

As a Legal Deposit library we process physical and born digital material in the same way through Acquisitions; creating bib records (often pre-publication), POLs and claiming if we don't receive material in the expected timeframe. We need the new Digital POLs to work as close to the Physical workflow as possible.

The new born digital workflow assumes that we have the file in hand and can attach the representation when we create the POL. That is not always the case for us as we create a lot of POLs pre-publication as well as for material where we then need to seek publisher assistance with getting the file.

Also all of the claiming functionality of the physical workflow is not in the new digital workflow. Our understanding is that this is driven by the expected receipt date with is not included in the new POL types.

For Continuous physical POLs we follow the same workflow but include a Subscription Interval to reflect the publication frequency (daily, weekly, monthly etc). With no Interval in the Digital Subscription POL it looks like there is no anticipation of the next issue and no facility to shift the POL into the claims workflow if a rep is not attached within the Interval + Grace period.

We would like to see an expected receipt date, Subscription interval and the ability to 'Order Now' without a rep being attached. Ideally this would feed into the existing claims and communications workflows if the rep is not attached before the expected receipt date.

A step by step of our current physical workflow and our testing of the new Digital POLs is attached.