Because all norm rules can be edited by all staff with cataloger roles, there is great room for erroneous changes for rules that are applied to batch jobs. For example, the norm rule that is applied to records being brought in from Z39.50 targets can be edited by any staff member. A single error in the rule can break the z39.50 import process for all staff until the source of the error is identified. Likewise, if we have a rule applied to import profiles and a staff member inadvertently changes it and we load 50,000 records, that could cause huge data corruption. There needs to be a way to secure a norm rule to administrators such that normal staff with cataloger roles cannot change them.

Alma authority control does not handle cases where the bib heading is linked to an authority via a cross-reference, but the preferred and non-preferred terms are in different fields, e.g. preferred term is in authority field 130 and cross-reference in authority is in 410.

Alma should be able to handle this scenario. Currently when the bib heading matches the authority cross-reference, Alma won't correct these and instead puts them on this report: Preferred Term Correction - Bib Heading found no authorized term.

Example bib heading that Alma won't correct:

110/2_ $$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28.

The authority record that this heading links to (via its cross-reference)

130/_0 $$a Treaty of Versailles $$d (1919 June 28)
410/2_$$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28

The bib heading in 110 links to the authority via the cross-reference in the 410, but because the preferred term in the authority is in 130 (and not 110), Alma will not flip the heading.

We would like to be able to copy multiple lines from MARC records and paste them into the metadata editor so that multiple MARC fields are pasted into the record in one action. This would help us enormously with our workflow of importing MARC authority records from LibrariesAustralia into Alma.

For us, this is necessary because the LibrariesAustralia headings are not in the community zone and are unlikely to ever be included there and Alma does not allow for Z39.50 import of authority headings.

We have this functionality of copying and pasting multiple fields in the LibrariesAustralia Cataloguing Client and other library systems allow it. At the moment we need to paste each line one by one into Alma and it is slow and repetitive. This process is a step backward from previous functionality.

When a 655 field is coded for LCSH and matches a non-preferred term in LCGFT, Alma flips the heading to the preferred LCGFT term but does not update the coding (it should change the 2nd ind to 7 and add $2 lcgft).

The problem is limited to cases where:

A bib heading 655/_0 matches a non-preferred term in an LCGFT authority

What happens is:

The PTC job flips the heading to the LCGFT preferred form, but it does not change the 2nd-indicator from 0 to 7, and does not add $2lcgft

What is not a problem:

655/_0 headings that already match preferred LCSH/LCGFT form
655/_7, $2 lcgft (these get controlled appropriately)
655/_7, $2 fast (these get controlled appropriately)
655/_7, $2 any other vocab (these do not get controlled)


Example of the bug:

Before: 655/_0 $a Dissertations, Academic
After: 655/_0 $a Academic theses.

Here is an enhancement request concerning bibliographic records editing history.

Currently, the "View Versions" can only tell the different version of a bib. record. However, this cannot tell logging history of updating/editing the bib. records, e.g. who add/remove a MARC fields/who suppressed/released the bib. record etc. This is no history tab to keep tracking the changes of a bib. record which is unlike other history tab functionality available in other Alma pages, e.g.

• The PO Line Summary page when editing a PO line
• The Physical Item Editor page when editing item records
• The License Terms Details page when editing license details

It is good to know logging history of updating/editing the bib. record for a record life cycle.

Lists of Name Authorities similar Subject Authorities
When cataloging a bibliographic record, Alma allows selecting different lists of Subject Authorities (LC, UC or UANDES, etc.). In the case of the Name Authorities, it currently only allows the use of a list of Name Authorities. We propose that the authorities of name are handled in the same way as the Matter Authorities.

// Al momento de catalogar un registro bibliográfico, Alma
permite seleccionar distintos listados de Autoridades de Materia (LC, UC o UANDES, etc.). En el caso de las Autoridades de Nombre, actualmente sólo permite usar un listado de Autoridades de Nombre. Proponemos que las autoridades de nombre se manejen igual que las Autoridades de Materia.

Currently, the OCLC Number for a record is indexed in the search index "Other System Number." This is not ideal, since the Other System Number indexes other numbers related to vendor record, CONSER, related item, etc.
We request that Ex Libris provide a separate search index for OCLC number based on the presence of the '(OCoLC)' prefix in the 035 $a and/or $z, or (without prefix) in the 019 $a if there is a number in the 035 with an (OCoLC) prefix. Currently these specific (OCoLC) numbers are mixed in with other numbers occurring in the 019, 035, 773, 774, 775 777, 786, 800, 810, 811, 830 $w tags and subfields. Disambiguating these specific (OCoLC) numbers from the "other system numbers" would allow us to use them as unique identifiers. We see the potential for: Improved search Improved matching upon record import Cleaner Excel exports from Alma (we currently have to clean this field every time we export) Creation of a new Analytics field for OCLC number in Alma Analytics Establishment of a model for non-OCLC systems to create other unique search indexes 

It is possible to create an All Titles set from a list of MMS IDs, but not a Physical Titles or Physical Items set. To run certain jobs – like Change Holdings Information – a Physical Titles set is required. In order to run this job on a list of MMS IDs, you must first create an All Titles set, then extract some other key like OCLC #, then create a Physical Titles set from that list, and only then can you run your job. Since all physical titles and items DO have MMS IDs, it should be possible to create a Physical Titles or Physical Items set from a list of MMS IDs.