Rosetta offers an IE level export task that can be used with IE level sets and exports the whole IE/Representation. What we need in addition, is a file level export task. It should be possible to export sets of files (itemized sets based on a list of FL IDs, or logical sets based on search criteria, e.g. IE PID and file extension) to a given export path. Subdirectory name could be the set ID.

To date, the only options are file download – one at time – or IE export, which means unpacking the Rep.tar containers and selecting the required files. Both options are rather tedious.

Use Cases: A user requests a set of high-resolution images for publication, e.g. several pages from a digitized book or a collection of images from different sources.

we are using the Rosetta-Aleph-Integration in both directions:
1. creating the CMS-record in Rosetta and
2. setting the Rosetta-flag in Aleph as well as updating the Aleph record with the URN created in Rosetta.
In the past there was only one target field for the URN and the assignCMS task with updateURNTask worked without problems.

Due to changes in the cataloging rules - we are using now the international RDA-rules - we have to deal now with different target fields in Aleph for the URN depending on the type of material: e-only e-books, digital reproductions of printed books, online versions of printed books, etc.

The target field is configurable in the Rosetta-Aleph-Sync, but this is not sufficient with the new situation. We want to be able to configure profiles for the updateURNTask depending on the material type: to specify the target MARC-field, to populate subfields with fixed information depending on the material type and with the URN.
(It is not possible at the moment to update the URN in a subfield of an already existing field, a new field is created (case 00510676)).

Astrid Schoger on behalf of the Bavarian State Library

Right now when you use the Create Derivative Copy task you have to select a plug-in type (either Transformation Profile or Stream Handler) even in cases where you are not transforming anything - we create derivative copy representations that are exact copies of the preservation master representation with no transformations. I would like to have a 3rd radio button - something like "None" - added. Since we're not selecting any file formats and we are choosing "Copy other extensions" the system is doing what we need it to do and we think it's odd to have to choose a plugin type when it's not being used. Low priority, but worth mentioning I thought. Thanks!

For compliance purposes and as a lesson learned from SC 00560356, I suggest improving the documentation and configurability of passwords throughout subsystems of Rosetta installations.

I suggest creating and maintaining a KB article on how and where to change passwords for:
- System user "dps"
- System user "oracle"
- Oracle user "sys"
- default Rosetta user "admin1" (John Smith)
- Cantaloupe Image Server user "admin" (changeable by configuring ".../system.dir/thirdparty/tomcat/rosetta-webapps/cantaloupe.war/cantaloupe.properties")
- Solr user
- Rosetta console UI user

The passwords for Solr and the Rosetta console UI cannot be changed at the moment (Rosetta 5.5.0.0); I suggest considering changes to enable institutions to set their own passwords.

Furthermore, I suggest that ExLibris set up suitable infrastructure for exchanging passwords securely. GPG-encrypted mail or a public write-only (!) storage would be suitable candidates, SupportCase comments (that might be publicly readable) and encrypted mobile instant messaging services like Signal (that often involve personal accounts/devices) are certainly not.

Increasingly libraries and consortia are using counter / sushi to measure usage of digital and electronic resources across disparate parts of their holdings.

If holdings being held in Rosetta are to be valued by the broader institutions funding and maintaining those resources, we need to be able to report usage using the counter and sushi protocols (which ExLibris has already demonstrated knowledge of in their support in ALMA and 265 services).

Key features would be basic counter and sushi reporting; use of IP ranges and user groups already defined in Rosetta for reporting; and grouping or content by already defined sets and/or collections for reporting.

submitted on behalf of Michele Lindlar

Sometimes it's neccessary to update our cms metadata. if a librarian changes a record in the external cms-system, we want to update the record in rosetta too, but there's no task that works accordingly. we'd be really happy if there would be a task chain or a process that re-harvest existing cms-records.

We currently integrate two catalogue systems via SRU in Rosetta: Aleph and Pica. Both systems are integrated uni-directoinal, as in a Rosetta flag is not available in either cataloguing system. As we are integrating the union catalogues which are held by third parties, we are not at liberty of including any Rosetta-specific fields in the catalogue.

The initial CMS enrichment works without a problem. However, at times it becomes necessary to update the CMS information stored in Rosetta. This can be the case when either the catalogue was updated or when we have detected an error in our mapping.

While two tasks are available which suggest a working update - namely, "Re-Assign CMS" and "CMS Metadata Record Update" - these tasks will not re-harvest from the source CMS included in the SRU integration but will instead always pull from the physical MID copy already stored in the /metadata storage of Rosetta.
Actual re-harvesting is only possible by first manually deleting the MID record in the file storage and then re-harvesting.

ExL has provided us with a script which can be run across the file system. The script requires a list of CMS Ids first and then deletes the records from the storage. The script needs to be run by the administrator from the shell.

We do not consider the script solution sufficient. Instead, we require a functionality of re-enriching with updating CMS records from the integrated CMS system from within Rosetta.

Rosetta knows two CMS integration options: unidirectional and bi-directional. The bidirectional integration requires a Rosetta flag to be set in the CMS system. Via the flag, all Rosetta-relevant records from the CMS can be gathered and the metadata pool within Rosetta updated in bulk on a regular basis. However, institutions may be using a CMS for enrichment which belongs to a different / external institution, making the addition of a Rosetta-flag within the CMS system impossible.
This is where the unidirectional enrichment comes to play. The CMS is queried via SRU integration and records are pulled into Rosetta. The pre-requisite is that a CMS section is present within the ie.xml, containing a system name and identifier to automatically query the CMS. This works well exactly once - duirng the first enrichment of the IE from within Rosetta. While all required information to re-query the CMS is present within Rosetta, any re-enrichment attempts via Task Chains such as "Re-assign CMS" or via manual "remove" / "link" will not requery the CMS system but always pull the information from the rosetta-side shared metadata directoy containing the initial harvest. Not only is this behavior counter-intuitive, it also prohibits the update of CMS data for those institutions who do not have control over the source CMS they are enriching from.
Ex Libris has provided a script via which the re-enrichment of these records is possible. The script takes a list of CMS identifiers as an input parameter and returns newly harvested CMS records into the shared metadata folder. However, running the script requires shell access to the application servers and can therefore only be done by system administrators.
It seems that all the basic functionatily for re-enrichment is there, it's just not available in the UI. The users who typically conduct re-enrichment of CMS data, however, do not work via the shell, they work in the UI and expect the functionality to be included there.

Our idea proposed here is to make the re-enrichment mechamism avaiable via the script actionable via the UI. We urgently require this functionalilty as the experience of the past years has shown that CMS records DO change and that these changes are monitored by Rosetta staff users such as participating institutions in a consortia, who do not have sufficient rights to run shell scripts for updates.

We do not wish to have all of our institutional users in Rosetta, leaving that for administrators and publishers.

When a user has signed in successfully through SSO (in our case ADFS) we know that they are from our institution, so we should be able to do access rights rules based on this.

We are also able to pass through extra parameters through SAML to identify the type of user, and where they have come from, it would be great to be able to assign such users to basic user accounts so we can have granular access rights to IE's and Reps within Rosetta.